# §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 ConstructorDeclarator

Note, that ResultType, MethodDeclarator and ConstructorDeclarator are not explicit in the overall syntax of the Java language specification. For convenience we refer to the definition in sections 8.4. Method Declarations and 8.8. Constructor 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. `CalloutBinding`s and `CallinBinding`s 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.
5. A `MethodSpec` of the shape `ConstructorDeclarator` is legal only on the right hand side of a callin after binding (see §4.1.(i)).

## §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 package QualifiedName ;

§ A.10.2 | Import ... import base QualifiedName ;