The Fortress Language Specification - CiteSeerX

α, β type variables
f
method name
x
field name
T
trait name
O
object name
τ, τ ′ , τ ′′ ::= α type
| σ
σ ::= N type that is not a type variable
| O −→ τ
N, M, L ::= T −→ τ type that can be a type bound
| Object
e ::= x expression
| self
| O −→ τ ( −→ e )
| e.x
| e.f −→ τ ( −→ e )
fd ::= f −−−−−−−−−→ αextends N( −→ x:τ):τ = e
method definition
td ::= trait T −−−−−−−−−→ αextends Nextends { −→ N } −→ fd end trait definition
od ::= object O −−−−−−−−−→ αextends N( −→ x:τ)extends { −→ N } −→ fd end object definition
d ::= td definition
| od
p ::= −→ d e program
Figure A.1: Syntax of Basic Core Fortress
Fortress dynamic semantics consists of two evaluations rules: one for field access and another for method invocation.
For simplicity, we use ‘ ’ to denote some parts of the syntax that do not have key roles in a rule. We assume that
does not expand across definition boundaries unless the entire definition is included in it.
A.1.3
Static Semantics
A static semantics for Basic Core Fortress is provided in Figures A.3, A.4, and A.5. The Basic Core Fortress static
semantics is based on the static semantics of Featherweight Generic Java (FGJ) [12]. The major difference is the
division of classes into traits and objects. Both trait and object definitions include method definitions but only object
definitions include field definitions. With traits, Basic Core Fortress supports multiple inheritance. However, due to
the similarity of traits and objects, many of the rules in the Basic Core Fortress dynamic and static semantics combine
the two cases. Note that Basic Core Fortress allows parametric polymorphism, subtype polymorphism, and overriding
in much the same way that FGJ does.
We proved the type soundness of Basic Core Fortress using the standard technique of proving a progress theorem and
a subject reduction theorem.
314