Latest News

 all news    RSS feed
↑ Table of Contents ↑

§A OT/J Syntax

Notation

The following grammar rules extend the Java grammar given in the Java Language Specification. We adopt the conventions of printing non-terminal symbols in italic font (e.g., ClassDeclaration), and terminal symbols in roman font (e.g., class). Names printed in black refer to definitions from the original Java grammar. Object Teams additions are printed in blue boldface. For those rules that simply add a new option to an existing rule, the original options are indicated by an ellipse (...).

§A.0 Keywords↑ §A

The keywords introduced by OT/J have different scopes, which means outside their given scope these keywords can be used for regular identifiers. Only these names are keywords unconditionally: 

readonly, team, within

§A.0.1 Scoped keywords↑ §A.0

The following names are keywords in OT/J only if they appear within a team or role class, ie., after the keyword team has been recognized: 

as, base, callin, playedBy, precedence, tsuper, with, when

These names are keywords only in the context of a callin or callout binding respectively (§A.3): 

after, before, replace, get, set

§A.0.2 Inheriting scoped keywords↑ §A.0

While regular Java classes may use the scoped keywords (§A.0.1) of OT/J freely, it is an error if a role class inherits a feature whose name is a scoped keyword.

§A.0.3 Internal names↑ §A.0

Compiler and runtime environment generate internal methods and fields which start with the prefix _OT$. It is illegal to use any of these methods and fields within client code.

§A.1 Class definitions↑ §A

Class definitions add two new keywords team and playedBy. Classes which use these keywords are called teams and bound roles, respectively. Any class that inherits from a bound role class (either by an extends clause or by implicit inheritance, cf. §1.3.1.(c)) is again a bound role class.

§ A.1.1 ClassDeclaration
[Modifiers] [team] class Identifier [extends Type] [implements TypeList]
[playedBy Type] [Guard] ClassBody
Contextual constraints:
  1. A class which has a playedBy clause (a bound role class) may not be declared static and must be directly contained in a class that has the team modifier (a team class).
  2. A class which inherits from a team class must have the team modifier, too.
  3. A class which has a guard (see §5.4) must be a team or a role.

§A.2 Modifiers↑ §A

The rule for method modifiers adds one keyword: callin:

§ A.2.1 Modifier
...
callin
Contextual constraints:
  1. The class of a method which has the callin modifier may not be declared static and must be directly contained in a team class.
  2. A method that has the callin modifier may not appear in an explicit method call (rule Apply in JLS).

§A.3 Method bindings↑ §A

The rule of items declarable in a class body is augmented by method bindings:

§ A.3.1 ClassBodyDeclaration
...
CalloutBinding
CallinBinding
§ A.3.2 CalloutBinding
[Modifier] [TypeArguments] MethodSpec CalloutKind MethodSpec CalloutParameterMappings
[Modifier] [TypeArguments] MethodSpec CalloutKind CalloutModifier FieldSpec
§ A.3.3 Callin binding
[ Identifier : ] [TypeArguments] MethodSpec <- CallinModifier MethodSpecs
[Guard] CallinParameterMappings
§ A.3.4 MethodSpec
Identifier
ResultType MethodDeclarator
Note, that ResultType and MethodDeclarator are not explicit in the overall syntax of the Java language specification. For convenience we refer to the definition in section 8.4. Method Declarations of the Java language specification.
§ A.3.5 MethodSpecs
MethodSpec [, MethodSpecs]
§ A.3.6 CalloutKind
->
=>
§ A.3.7 CallinModifier
before
after
replace
§ A.3.8 CalloutModifier
get
set
§ A.3.9 FieldSpec
[Type] Identifier
Contextual constraints:
  1. CalloutBindings and CallinBindings may occur only in bound role classes.
  2. A CalloutBinding or CallinBinding may not mix identifiers and full signatures (MethodDeclarationHead) for its method specifiers (MethodSpec).
    Binding a full method signature to a field requires the FieldSpec to include the Type.
  3. The method specifier at the left hand side of a CallinBinding which has the replace modifier must refer to a method that has the callin modifier.
  4. The Modifier of a callout binding can only be one of the visility modifiers public, protected or private. A short callout binding (i.e., without signatures) must not specify a visibility modifier.

§A.4 Parameter mappings↑ §A

§ A.4.1 CalloutParameterMappings
with { CalloutParameterMappingList [,] }
;
§ A.4.2 CallinParameterMappings
with { CallinParameterMappingList [,] }
;
§ A.4.3 CalloutParameterMappingList
CalloutParameterMapping [, CalloutParameterMappingList]
§ A.4.4 CallinParameterMappingList
CallinParameterMapping [, CallinParameterMappingList]
§ A.4.5 CalloutParameterMapping
Expression -> Identifier
result <- Expression
§ A.4.6 CallinParameterMapping
Identifier <- Expression
Expression -> result
Note:
By defining ";" as an option for parameter mappings, the grammar enforces that method bindings without a parameter mapping are terminated by a ";". Also method bindings with parameter mappings may optionally be terminated by a ";", which in that case is interpreted as an empty member declaration, following the same pattern how non-abstract methods in Java may optionally have a trailing ";".

§A.5 Statements↑ §A

§ A.5.1 Statement
...
Within
BaseCall
TSuperCall
§ A.5.2 Within
within ( Expression ) Statement
§ A.5.3 BaseCall
base . Identifier ( Argumentsopt )
base ( Argumentsopt )
§ A.5.4 TSuperCall
tsuper . Identifier ( Argumentsopt )
tsuper ( Argumentsopt )
Contextual constraints:
  1. The expression of a Within must evaluate to an instance of a team class.
  2. The first form of a BaseCall may occur only in the body of a method that has the callin modifier. The identifier must be the name of the enclosing method.
  3. The second form of a BaseCall may occur only in a constructor of a bound role class.
  4. The first form of a TSuperCall may occur only in a method of a role class.
  5. The second form of a TSuperCall may occur only in a constructor of a role class.

§A.6 Types↑ §A

§ A.6.1 Type
...
LiftingType
AnchoredType
§ A.6.2 LiftingType
Type as Type
§ A.6.3 AnchoredType
Path.Type
§ A.6.4 Path
Identifier
Path.Identifier
Contextual constraints:
  1. Location
    A LiftingType may only occur in the parameter list of a method of a team class.
  2. Role in scope
    The right hand side type in a LiftingType must be a class directly contained in the enclosing team class (the class may be acquired by implicit inheritance (§1.3.1.(c))).
  3. Team path
    Note, that the syntax of §A.6.3/4 is deprecated in favor of §A.9.
    The path in an AnchoredType must refer to an instance of a team class. Each identifier in the path must be declared with the final modifier.

§A.7 Guard predicates↑ §A

§ A.7.1 Guard
[base] when ( Expression )
§ A.7.2 MethodDeclaration
...
MethodHeader [Guard] MethodBody

Other rules referring to Guard: ClassDeclaration (§A.1.1), CallinBinding (§A.3.3)

Contextual constraints:
  1. The Expression in a guard must have type boolean.

§A.8 Precedence declaration↑ §A

§ A.8.1 PrecedenceDeclaration
precedence [after] CallinNameList ;
§ A.8.2 CallinNameList
Name [, CallinNameList]

§A.9 Value dependent types↑ §A

§ A.9.1 TypeParameter
TypeVariable [TypeBound]
ReferenceType Name

See JLS 3 §4.4

§ A.9.2 ActualTypeArgument
ReferenceType
Wildcard
@Name

See JLS 3 §4.5.1

Contextual constraints:
  1. ActualTypeParameter
    An ActualTypeArgument of the form @Name may only occur as a parameter of a simple name type reference.

§A.10 Packages and imports↑ §A

§ A.10.1 PackageDeclaration
...
team QualifiedName ;
§ A.10.2 Import
...
import base QualifiedName ;
↑ Table of Contents ↑