The Ceylon Language

Ceylon programs execute in any standard Java Virtual Machine or on any JavaScript virtual machine, and take advantage of the memory management and concurrency features of the virtual machine in which they execute. Ceylon programs are packaged into modules with well-defined inter-module dependencies, and always execute inside a runtime environment with module isolation.

The Ceylon compiler is able to compile Ceylon code that calls Java classes or interfaces, and Java code that calls Ceylon classes or interfaces. JavaScript code is able to interact with Ceylon classes and functions compiled to JavaScript. Via a special dynamic mode, code written in Ceylon may call functions defined natively in JavaScript.

Moreover, Ceylon provides its own native SDK as a replacement for the Java platform class libraries. Certain SDK modules depend upon services available only on the Java platform. Other SDK modules, including the core language module, are cross-platform and may also be used in a JavaScript virtual machine.

Finally, the language supports the development of cross-platform modules that contain platform-specific implementation code, via the native annotation.

import java.lang { System }

shared native void hello();

shared native("jvm") void hello() {
    System.console()?.printf("Hello, world!");
}

shared native("js") void hello() {
    dynamic {
        alert("Hello, world!");
    }
}

Ceylon supports a restricted form of multiple inheritance, often called mixin inheritance. A class must extend exactly one other class. But a class or interface may satisfy (extend or implement) an arbitrary number of interfaces.

Classes hold state and define logic to initialize that state when the class is instantiated. A concrete class is a class that contains only concrete member definitions. Concrete classes may be directly instantiated. An abstract class may have formal (unimplemented) member declarations. Abstract classes may not be instantiated.

Interfaces may define concrete and formal members, but may not hold state (references to other objects) or initialization logic. This restriction helps eliminate the problems traditionally associated with multiple inheritance. Ceylon never performs any kind of "linearization" of the supertypes of a type. Interfaces may not be directly instantiated.

Ceylon does not feature Java-style enumerated types as a first-class construct. Instead, any abstract type may specify its cases—an enumerated list of instances and/or subtypes. This facility is used to simulate both enumerated types and functional-style algebraic sum types.

interface Identity of Person | Organization { ... }

abstract class Variance() of covariant | contravariant | invariant { ... }

A closely related feature is support for self types and type families. A self type is a type parameter of an abstract type (like Comparable) which represents the type of a concrete instantiation (like String) of the abstract type, within the definition of the abstract type itself.

interface Comparable<in Other> of Other
        given Other satisfies Comparable<Other> { ... }

In a type family, the self type of a type is declared not by the type itself, but by a containing type which groups together a set of related types.

Ceylon doesn't have raw types, implicit bounds, or wildcard capture. And the Ceylon compiler never even uses any kind of "non-denotable" type to reason about the type system. So generics-related error messages are understandable to humans.

Ceylon features declaration-site variance. A type parameter may be marked as covariant or contravariant by the class or interface that declares the parameter.

interface Source<out Item> { ... }
interface Sink<in Item> { ... }

In order to support interoperation with Java, Ceylon also features Java-style use-site variance, with a much cleaner syntax than Java's. A type argument may be marked as covariant or contravariant.

List<out Element> javaArrayList = ArrayList<Element>();

Ceylon has a somewhat more expressive system of generic type constraints with a cleaner, more regular syntax. The syntax for declaring constraints on a type parameter looks very similar to a class or interface declaration. A type parameter may have upper bound type constraints or even enumerated bounds.

interface Producer<out Value, in Rate> 
        given Value satisfies Object 
        given Rate of Float | Decimal { ... }

A union type, for example String|Number, or intersection type, for example Identifiable&List<String>, may be formed from two or more types defined elsewhere.

Union types make it possible to write code that operates polymorphically over types defined in disparate branches of the type hierarchy without the need for intermediate adaptor classes.

Float distance(Point|Location x, Point|Location y) => ... ;

Intersection types make it possible to operate polymorphically over all subtypes of a list of types.

void persistRemotely(Persistent&Serializable stuff) { ... }

Union and intersection types provide some of the benefits of structural ("duck") typing, within the confines of a nominative type system, and therefore certain Ceylon idioms are reminiscent of code written in dynamically-typed languages.

Union and intersection types underly the whole system of principal typing in Ceylon, forming the foundation for type inference and flow-sensitive typing. In particular, they play a central role in generic type argument inference. For example, the following expression has type HashMap<String,Integer|Float>:

HashMap { "float"->0.0, "integer"->0 }

Type aliases and type inference help reduce the verbosity of code which uses generic types, eliminating the need to repeatedly specify generic type arguments.

A type alias is similar to a C-style typedef.

interface Strings => Sequence<String>;

alias Number => Integer|Float|Whole|Decimal;

Local type inference allows a type annotation to be eliminated altogether. The type of a block-local value or function is inferred from its definition if the keyword value or function occurs in place of the type declaration.

value name = person.name;

function sqrt(Float x) => x^0.5;

The type of a control-structure variable also may be inferred.

for (n in 0..max) { ... }

Ceylon features an especially elegant approach to generic type argument inference, making it possible to instantiate container types, even inhomogeneous container types, without the need to explicitly mention any types at all.

value numbers = { -1, 0, -1, -1.0, 0.0, 1.0 };

By limiting type inference to local declarations, Ceylon ensures that all types may be inferred by the compiler in a single pass of the source code. Type inference works in the "downward" and "outward" directions. The compiler is able to determine the type of an expression without considering the rest of the statement or declaration in which it appears.

In other statically typed languages, runtime metaprogramming, or reflection, is a messy business involving untypesafe strings and typecasting. Even worse, in Java, generic type arguments are erased at runtime, and unavailable via reflection. Ceylon, uniquely, features a typesafe metamodel and typed metamodel expressions. Since generic type arguments are reified at runtime, the metamodel fully captures generic types at both compile time and execution time.

Attribute<String,Integer> stringSize = `String.size`;

Ceylon's support for program element annotations is based around this metamodel. Annotations are more flexible than in Java or C#, and have a much cleaner syntax.

A Ceylon class may have one or more named constructors, declared using the new keyword.

class Point {
    Float x; 
    Float y;
    new create(Float x, Float y) {
        this.x = x;
        this.y = y;
    }
    ...
}

However, since constructors are often unnecessarily verbose, it is more common to define a Ceylon class with a parameter list, and exactly one initializer—the body of the class.

class Point(Float x, Float y) { ... }

The Ceylon compiler guarantees that the value of any attribute of a class is initialized before it is used in an expression.

A class may be a member of an outer class. Such a member class may be refined (overridden) by a subclass of the outer class. Instantiation is therefore a polymorphic operation in Ceylon, eliminating the need for a factory method in some circumstances.

Ceylon provides a streamlined syntax for defining anonymous classes. An anonymous class is a class which is instantiated only in exactly the place it is defined. Among other uses, the object declaration is useful for creating singleton objects or locally-scoped interface implementations.

object origin extends Point(0.0, 0.0) {}

Strictly speaking, an object declaration is just an abbreviated way to write a class with a value constructor. A value constructor defines a named instance of a class:

class Point {
    Float x; 
    Float y;
    new create(Float x, Float y) {
        this.x = x;
        this.y = y;
    }
    new origin {
        this.x = 0.0;
        this.y = 0.0;
    }
    ...
}

Functions and values are the bread and butter of programming. Ceylon functions are similar to Java methods, except that they don't need to belong to a class. Ceylon values are polymorphic, and abstract their internal representation, similar to C# properties.

String name => firstName + " " + lastName;

A function belonging to a type is called a method. A value belonging to a type is called an attribute. A function or value may be declared as a direct toplevel member of a package, or as a member of a singleton anonymous class. This approach, along with certain other features, gives the language a more regular block structure.

The Ceylon compiler guarantees that any attribute or value is initialized before it is used in an expression. By default, an attribute or value may not be reassigned a new value after its initial value has been specified. Mutable attributes and variable values must be explicitly declared using the variable annotation.

variable value count = 0;

Ceylon does not support function overloading. Each method of a type has a distinct name.

Instead of method and constructor overloading, Ceylon supports parameters with default values and variadic parameters.

void addItem(Product product, Integer quantity=1) { ... }

String join(String* strings) { ... }

Union types also help alleviate the need for overloading.

String format(String formatString, String|Float|Integer* values) => ... ;

Therefore, a single method in Ceylon may emulate the signatures of several overloaded methods in Java.

Ceylon supports first-class function types and higher-order functions. A function declaration may specify a callable parameter that accepts references to other functions with a certain signature.

String find(Boolean where(String string)) { ... }

The argument of such a callable parameter may be either a reference to a named function declared elsewhere, or a new function defined inline as part of the method invocation.

value result = { "C", "Java", "Ceylon" }.find((String s) => s.size>1);

The type of a function is expressed within the type system as an instantiation of the interface Callable. The parameter types are expressed as a tuple type. So the type of the function (String s) => s.size>1 is Callable<Boolean,[String]>, which may be abbreviated to Boolean(String).

Unlike many other languages with higher-order functions, Ceylon supports abstraction over function and tuple types of arbitrary arity.

References to methods and attributes may also be used as functions.

value names = people.map(Person.name);

value values = keys.map(keyedValues.get);

The Ceylon compiler enforces the traditional Smalltalk naming convention: type names begin with an initial uppercase letter—for example, Liberty or RedWine—member names and local names with an initial lowercase letter or underscore—for example, blonde, immanentize() or boldlyGo().

These restrictions allow a much cleaner syntax for program element annotations than the syntax found in either Java or C#. Declaration "modifiers" like shared, abstract, and variable aren't keywords in Ceylon, they're ordinary annotations.

"Base type for higher-order abstract stuff."
shared abstract class AbstractMetaThingy() { ... }

The documentation compiler reads inline documentation specified using the doc annotation.

Ceylon's named argument lists provide an elegant means of initializing objects and collections. The goal of this facility is to replace the use of XML for expressing hierarchical structures such as documents, user interfaces, configuration and serialized data.

Html page = Html {
    doctype = html5;
    Head { title = "Ceylon: home page"; };
    Body {
        H2 ( "Welcome to Ceylon ``language.version``!" ),
        P ( "Now get your code on :)" )
    };
}

An especially important application of this facility is Ceylon's built-in support for program element annotations.

Toplevel declarations are organized into packages and modules. Ceylon features language-level access control via the shared annotation which can be used to express block-local, package-private, module-private, and public visibility for a program element. There's no equivalent to Java's protected.

A module corresponds to a versioned packaged archive. Its module descriptor expresses its dependencies to other modules. The tooling and execution model for the language is based around modularity and module archives.

Ceylon features a rich set of operators, including most of the operators supported by C and Java. True operator overloading is not supported. However, each operator is defined to act upon a certain class or interface type, allowing application of the operator to any class which extends or satisfies that type. For example, the + operator may be applied to any class that satisfies the interface Summable. This approach is called operator polymorphism.

Ceylon's numeric type system is much simpler than C, C# or Java, with exactly three built-in numeric types (compared to six in Java and eleven in C#). The built-in types are classes representing integers, floating point numbers, and bytes. Integer and Float values are signed, with 64 bits of precision by default, and may be optimized for 32 bit architectures via use of the small annotation. The Byte class represents 8-bit values with modular arithmetic, sidestepping the question of whether a byte is signed or unsigned.

The module ceylon.math provides two additional numeric types representing arbitrary precision integers and arbitrary precision decimals.

Ceylon has Character and String classes, and, unlike Java or C#, every character is a full 32-bit Unicode codepoint. Conveniently, a String is a List<Character>.

There is no primitive null in Ceylon. The null value is an instance of the class Null. An optional type is a union type like Null|String, which may be abbreviated to String?. An optional type is never assignable to a non-optional type except via use of the special-purpose if (exists ... ) construct. Thus, the Ceylon compiler is able to detect illegal use of a null value at compile time. Therefore, there is no equivalent to Java's NullPointerException in Ceylon.

Similarly, there are no C-style typecasts in Ceylon. Instead, the if (is ... ) and case (is ... ) constructs may be used to test and narrow the type of an object reference in one step, without risk of a ClassCastException. This facility is called flow-sensitive typing.

String name(Organization|Person entity) {
    switch (entity)
    case (is Organization) {
        return entity.tradeName else entity.legalName;
    }
    case (is Person) {
        return entity.nickName else entity.firstName;
    }
}

Alternatively, type assertions, written assert (is ... ) or assert (exists ... ) may be used to narrow the type of a reference.

value arg = process.arguments[0];
"must specify an amount"
assert (exists arg);
"not a legal positive integer amount"
assert (exists amount = parseInteger(arg), amount>0);

The combination of case (is ... ) with sum types amounts to a kind of language-level support for the visitor pattern.

The interface Iterable represents a stream of values, which might be evaluated lazily. This interface is of central importance in the language module, and so the language provides a syntactic abbreviation for the type of an iterable object. The abbreviation {String*} means Iterable<String>. There is a convenient syntax for instantiating an iterable object, given a list of values:

{String*} words = {"hello", "world", "goodbye"};

A nonempty iterable is an iterable object which always produces at least one value. A nonempty iterabe type is written {String+}. Distinguishing nonempty streams of values lets us correctly express the type of functions like max():

{Float+} oneOrMore = .... ;
{Float*} zeroOrMore = .... ;
Float maxOfOneOrMore = max(oneOrMore); //never null
Float? maxOfZeroOrMore = max(zeroOrMore); //might be null

Comprehensions are an expressive syntax for filtering and transforming streams of values. For example, they may be used when instantiating an iterable object or collection:

value adults = { for (p in people) if (p.age>18) p.name };

value peopleByName = HashMap { for (p in people) p.name->p };

Comprehensions are evaluated lazily.

Sequences are Ceylon's version of arrays. However, the Sequential interface does not provide operations for mutating the elements of the sequence—sequences are considered immutable. Because this interface is so useful, a type like Sequential<String> may be abbreviated to [String*], or, for the sake of tradition, to String[].

A nonempty sequence is a kind of sequence which always has at least one element. A nonempty sequence type is written [String+]. The special-purpose if (nonempty ... ) construct narrows a sequence type to a nonempty sequence type.

Tuples are a kind of sequence where the type of each element is encoded into the static type of the tuple. Tuple is just an ordinary class in Ceylon, but the language lets us write down tuple types using a streamlined syntax. For example, [Float,Float] is a pair of Floats. There's also a convenient syntax for instantiating tuples and accessing their elements.

[Float,Float] origin = [0.0, 0.0];
Float x = origin[0];
Float y = origin[1];
Null z = origin[2]; //only two elements!

Tuples and nonempty sequences support pattern-based destructuring.

value [x, y] = origin;

An integer literal may be expressed in decimal, hexadecimal, or binary notation:

IntegerLiteral: DecimalLiteral | HexLiteral | BinLiteral

A decimal literal has a list of digits and an optional magnitude:

DecimalLiteral: Digits Magnitude?

Hexadecimal literals are prefixed by #:

HexLiteral: "#" HexDigits

Binary literals are prefixed by $:

BinLiteral: "$" BinDigits

A floating point literal is distinguished by the presence of a decimal point or fractional magnitude:

FloatLiteral: NormalFloatLiteral | ShortcutFloatLiteral

Most floating point literals have a list of digits including a decimal point, and an optional exponent or magnitude.

NormalFloatLiteral: Digits "." FractionalDigits (Exponent | Magnitude | FractionalMagnitude)?

The decimal point is optional if a fractional magitude is specified.

ShortcutFloatLiteral: Digits FractionalMagnitude

Decimal digits may be separated into groups of three using an underscore.

Digits: Digit+ | Digit{1..3} ("_" Digit{3})+

FractionalDigits: Digit+ | (Digit{3} "_")+ Digit{1..3} 

Hexadecimal or binary digits may be separated into groups of four using an underscore. Hexadecimal digits may even be separated into groups of two.

HexDigits: HexDigit+ | HexDigit{1..4} ("_" HexDigit{4})+ | HexDigit{1..2} ("_" HexDigit{2})+

BinDigits: BinDigit+ | BinDigit{1..4} ("_" Digit{4})+

A digit is a decimal, hexadecimal, or binary digit.

Digit: "0".."9"

HexDigit: "0".."9" | "A".."F" | "a".."f"

BinDigit: "0"|"1"

A floating point literal may include either an exponent (for scientific notation) or a magnitude (an SI unit prefix). A decimal integer literal may include a magnitude.

Exponent: ("E"|"e") ("+"|"-")? Digit+

Magnitude: "k" | "M" | "G" | "T" | "P"

FractionalMagnitude: "m" | "u" | "n" | "p" | "f"

The magnitude of a numeric literal is interpreted as follows:

The following examples are legal numeric literals:

69

6.9

0.999e-10

1.0E2

10000

1_000_000

12_345.678_9

1.5k

12M

2.34p

5u

$1010_0101

#D00D

#FF_FF_FF

The following are not valid numeric literals:

.33  //Error: floating point literals may not begin with a decimal point

1.  //Error: floating point literals may not end with a decimal point

99E+3  //Error: floating point literals with an exponent must contain a decimal point

12_34  //Error: decimal digit groups must be of length three

#FF.00  //Error: floating point numbers may not be expressed in hexadecimal notation

A single character literal consists of a Unicode character, inside single quotes.

CharacterLiteral: "'" Character "'"

Character: ~("'" | "\") | EscapeSequence

A character may be identified by an escape sequence. Every escape sequence begins with a backslash. An escape sequence is replaced by its corresponding Unicode character during lexical analysis.

EscapeSequence: "\" (SingleCharacterEscape | "{" CharacterCode "}")

SingleCharacterEscape: "b" | "t" | "n" | "f" | "r" | "e" | "\" | """ | "'" | "`" | "0"

The single-character escape sequences have their traditional interpretations as Unicode characters:

A Unicode codepoint escape is a two-, four-, or six-digit hexadecimal literal representing an integer in the range 0 to 10FFFF, or a Unicode character name, surrounded by braces, and means the Unicode character with the specified codepoint or character name.

CharacterCode: "#" ( HexDigit{2} | HexDigit{4} | HexDigit{6} ) | UnicodeCharacterName

Legal Unicode character names are defined by the Unicode specification.

The following are legal character literals:

'A'

'#'

' '

'\n'

'\{#212B}'

'\{ALCHEMICAL SYMBOL FOR GOLD}'

A character string literal is a sequence of Unicode characters, inside double quotes.

StringLiteral: """ StringCharacter* """

StringCharacter: ~( "\" | """ | "`" ) | "`" ~"`" | EscapeSequence | EscapedBreak

A string literal may contain escape sequences. An escape sequence is replaced by its corresponding Unicode character during lexical analysis.

A line-terminating character sequence may be escaped with a backslash, in which case the escaped line termination is removed from the string literal during lexical analysis.

EscapedBreak: "\" (CarriageReturn Newline | CarriageReturn | Newline)

A sequence of two backticks is used to delimit an interpolated expression embedded in a string template.

StringStart: """ StringCharacter* "``"

StringMid: "``" StringCharacter* "``"

StringEnd: "``" StringCharacter* """

A verbatim string is a character sequence delimited by a sequence of three double quotes. Verbatim strings do not contain escape sequences or interpolated expressions, so every character occurring inside the verbatim string is interpreted literally.

VerbatimStringLiteral: """"" VerbatimCharacter* """""

VerbatimCharacter: ~""" | """ ~""" | """ """ ~"""

The following are legal strings:

"Hello!"

"\{#00E5}ngstr\{#00F6}ms"

" \t\n\f\r,;:"

"\{POLICE CAR} \{TROLLEYBUS} \{WOMAN WITH BUNNY EARS}"

"""This program prints "hello world" to the console."""

The column in which the first character of a string literal occurs, excluding the opening quote characters, is called the initial column of the string literal. Every following line of a multiline string literal must contain whitespace up to the initial column. That is, if the string contents begin at the nth character in a line of text, the following lines must start with n whitespace characters. This required whitespace is removed from the string literal during lexical analysis.

Overloading is illegal in Ceylon. A type may not have:

A type may be a subtype of another type. Subtyping obeys the following rules:

Also, every interface type is a subtype of the class Object defined in ceylon.language.

If X is a subtype of Y, then:

Furthermore, we say that X is assignable to Y.

For any types X and Y, the union, or disjunction, X|Y, of the types may be formed. A union type is a supertype of both of the given types X and Y, and an instance of either type is an instance of the union type.

The union type constructor | is associative, so the union of three types, X, Y, and Z, may be written X|Y|Z.

UnionType: IntersectionType ("|" IntersectionType)*

If X and Y are both subtypes of a third type Z, then X|Y inherits all members of Z.

void write(String|Integer|Float printable) { ... }

Union types satisfy the following rules, for any types X, Y, and Z:

The following results follow from these rules:

Finally:

For any types X and Y, the intersection, or conjunction, X&Y, of the types may be formed. An intersection type is a subtype of both of the given types X and Y, and any object which is an instance of both types is an instance of the intersection type.

The intersection type constructor & is associative, so the intersection of three types, X, Y, and Z, may be written X&Y&Z.

IntersectionType: PrimaryType ("&" PrimaryType)*

The intersection X&Y inherits all members of both X and Y.

void store(Persistent&Printable&Identifiable storable) { ... }

Intersection types satisfy the following rules, for any types X, Y, and Z:

The following results follow from these rules:

Finally:

The special type Nothing, sometimes called the bottom type, represents:

Nothing is assignable to all other types, but has no instances.

The type schema for Nothing is empty, that is, it is considered to have no members.

Nothing is considered to belong to the module ceylon.language. However, it cannot be defined within the language.

Because of the restrictions imposed by Ceylon's mixin inheritance model:

Furthermore, as a special case,

An expression, as defined in Chapter 6, Expressions, occurring at a certain location, may be assignable to a type. In this case, every evaluation of the expression at runtime produces an instance of a class that is a subtype of the type, or results in a thrown exception, as defined in Chapter 8, Execution.

Given an expression occurring at a certain location, a type T is the principal type of the expression if, given any type U to which the expression is assignable, T is a subtype of U. Thus, the principal type is the "most precise" type for the expression. The type system guarantees that every expression has a principal type. Thus, we refer uniquely to the type of an expression, meaning its principal type at the location at which it occurs.

Function and value declarations usually declare a type, by specifying a type expression.

Type: UnionType | EntryType

Type expressions are formed by combining types using union, intersection, and type abbreviations.

Type expressions support grouping using angle brackets:

GroupedType: "<" Type ">"

Applied types are identified by the name of the type (a class, interface, type alias, or type parameter), together with a list of type arguments if the type declaration is generic.

TypeNameWithArguments: TypeName TypeArguments?

Type names are resolved to type declarations according to §5.1.7 Unqualified reference resolution and §5.1.8 Qualified reference resolution.

If the type is a class, interface, or type alias nested inside a containing class or interface, the type must be fully qualified by its containing types, except when used inside the body of a containing type.

BaseType: PackageQualifier? TypeNameWithArguments | GroupedType

QualifiedType: BaseType ("." TypeNameWithArguments)*

If a type declaration is generic, a type argument list must be specified. If a type declaration is not generic, no type argument list may be specified.

A base type may be qualified by the package keyword, allowing disambiguation of the type name, as defined in §5.1.7 Unqualified reference resolution.

PackageQualifier: "package" "."

BufferedReader.Buffer

Entry<Integer,Element>

Certain important types may be written using an abbreviated syntax.

PrimaryType: AtomicType | OptionalType | SequenceType | CallableType

AtomicType: QualifiedType | EmptyType | TupleType | IterableType

First, there are postfix-style abbreviations for optional types and sequence types.

OptionalType: PrimaryType "?"

SequenceType: PrimaryType "[" "]"

For any type X:

Next, there are type abbreviations for callable types which represent the types of functions.

CallableType: PrimaryType "(" (TypeList? | SpreadType) ")"

TypeList: (DefaultedType ",")* (DefaultedType | VariadicType)

DefaultedType: Type "="?

VariadicType: UnionType ("*" | "+")

SpreadType: "*" UnionType

For any type X:

More precisely, the type meant by a callable type abbreviation is Callable<X,T> where X is the type outside the parentheses in the the callable type abbreviation, and T is the tuple type formed by the types listed inside the parentheses.

Next, abbreviations for iterable types are written using braces.

IterableType: "{" UnionType ("*"|"+") "}"

For any type X:

Next, abbreviations for sequence types and tuple types may be written using brackets.

EmptyType: "[" "]"

TupleType: "[" TypeList "]" | PrimaryType "[" DecimalLiteral "]"

More precisely:

In a tuple type or callable type expression:

In a tuple type or callable type expression, every defaulted element must occur after every required element.

Finally, an entry type may be abbreviated using an arrow.

EntryType: UnionType "->" UnionType

Abbreviations may be combined:

String?[] words = { "hello", "world", null };
String? firstWord = words[0];

String->[Integer,Integer] onetwo = "onetwo"->[1, 2];

[Float+](Float x, Float[] xs) add = (Float x, Float[] xs) => [x, *xs];

When a type appears in a value expression, these abbreviations cannot be used (they cannot be disambiguated from operator expressions).

Certain declarations which usually require an explicit type may omit the type, forcing the compiler to infer it, by specifying the keyword value, as defined in §4.8.4 Value type inference, or function, as defined in §4.7.4 Function return type inference, where the type usually appears.

value names = people*.name;

function parse(String text) => text.split(" .!?,:;()\n\f\r\t".contains);

Type inference is only allowed for declarations which are referred to only by statements and declarations that occur within the lexical scope of the declaration, as specified by §5.1.6 Type inference and block structure. A value or function declaration may not:

Nor may a parameter or forward-declared value, as defined in §4.8.5 Forward declaration of values, or of a forward-declared function, as defined in §4.7.5 Forward declaration of functions, have an inferred type.

These restrictions allow the compiler to infer undeclared types in a single pass of the code.

value one;
if (float) {
    one = 1.0;
    Float float = one;
}
else {
    one = 1;
    Integer int = one;
}
Float|Integer num = one;

An inferred type never involves an anonymous class, as defined in §4.5.7 Anonymous classes. When an inferred type would involve an anonymous class type, the anonymous class is replaced by the intersection of the class type it extends with all interface types it satisfies.

A type alias is a synonym for another type. A generic type alias is a type constructor that produces a type alias, given a list of type arguments.

Every type alias must be reducible to an equivalent type that does not involve any type aliases by recursive replacement of type aliases with the types they alias. Thus, circular type alias definitions, as in the following example, are illegal:

alias X => List<Y>;  //error: circular type alias definition
alias Y => List<X>;  //error: circular type alias definition

Replacement of type aliases with the types they alias occurs at compile time, so type aliases are not reified types, as specified in §8.1.2 Type argument reification.

Inheritance relationships between classes, interfaces, and type parameters result in subtyping relationships between types.

A class may extend another class, in which case the first class is a subtype of the second class and inherits its members. A class which extends another class may have a constructor, as defined in §4.9 Constructors, which delegates to a callable constructor of the second class. Extension and constructor delegation is specified using the extends clause.

The extends clause must specify exactly one class or constructor.

ExtendedType: "extends" (Extension | Construction)

An extends clause of a class or constructor has either:

In the case that the extends clause refers to a constructor, the superclass is taken to be the class to which the constructor belongs.

Extension: (BaseExtension | SuperExtension) PositionalArguments?

Construction: (BaseConstruction | SuperConstruction) PositionalArguments

The extends clause may not refer to a partial constructor of the superclass, nor to a value constructor of the superclass.

BaseExtension: PackageQualifier? TypeNameWithArguments

SuperExtension: SuperQualifier TypeNameWithArguments

BaseConstruction: (PackageQualifier? TypeNameWithArguments ".")? MemberNameWithArguments

SuperConstruction: SuperQualifier MemberNameWithArguments

SuperQualifier: "super" "."

The specification of the superclass or superclass constructor is treated as a value expression, not as a type expression.

The type of the value expression is the inherited type.

The specification of the superclass or superclass constructor may have type arguments, and, additionally, the extends clause may have a positional argument list:

The type arguments may not be inferred from the positional arguments.

A type argument occurring in the extends clause may not involve variance annotations in or out, defined below in §3.6.1 Type arguments and variance.

extends Singleton<String>("")

extends Person(name, org)

extends withName(name)

A member class annotated actual may use the qualifier super in the extends clause to refer to the member class it refines. When the qualifier super appears, the following class name refers to a member class of the superclass of the class that contains the member class annotated actual.

extends super.Buffer()

The root class Anything defined in ceylon.language does not have a superclass.

The satisfies clause does double duty. It's used to specify that a class or interface is a direct subtype of one or more interfaces, and to specify upper bound type constraints applying to a type parameter.

The satisfies clause may specify multiple types.

SatisfiedTypes: "satisfies" PrimaryType ("&" PrimaryType)*

If a satisfied class or interface is a parameterized type, the satisfies clause must explicitly specify type arguments, and the resulting applied type is inherited.

A type occurring in the satisfies clause may not involve variance annotations in or out, defined below in §3.6.1 Type arguments and variance.

satisfies Correspondence<Integer,Element> & Collection<Element>

A satisfies clause may not contain two instantiations of the same type declaration.

Coverage is a strictly weaker relationship than assignability:

It follows that coverage obeys the identity property of assignability: a type covers itself. However, coverage does not obey the noncircularity property of assignability. It is possible to have distinct types A and B where A covers B and B covers A.

Case enumeration allows safe use of a type in a switch statement, or as the subject of the of operator. The compiler is able to statically validate that the switch contains an exhaustive list of all cases of the type, by checking that the union of cases enumerated in the switch covers the type, or that the second operand of of covers the type.

The of clause does triple duty. It's used to define self types and type families, enumerated types, and enumerated type constraints. The of clause may specify multiple elements, called cases.

CaseTypes: "of" CaseType ("|" CaseType)*

CaseType: ValueCase | PrimaryType

ValueCase: ("package" ".")? MemberName

A type occurring in the of clause may not involve variance annotations in or out, defined below in §3.6.1 Type arguments and variance.

If an interface or abstract class with an of clause has exactly one case, and it is a type parameter of the interface or abstract class, or of the immediately containing type, if any, then that type parameter is a self type of the interface or abstract class, and:

shared abstract class Comparable<Other>() of Other 
        given Other satisfies Comparable<Other> {
    
    shared formal Integer compare(Other that);
    
    shared Integer reverseCompare(Other that) 
            => that.compare(this) of Other;
    
}

Comparable<Item> comp = ... ;
Item item = comp of Item;

Otherwise, an interface or abstract class with an of clause may have multiple cases, but each case must be either:

Then the interface or abstract class is an enumerated type, and every subtype of the interface or abstract class must be a subtype of exactly one of the enumerated subtypes. A class or interface may not be a subtype of more than one case of an enumerated type.

If a concrete class has an of clause, then each case must be a value reference to a value constructor of the class, as defined in §4.9 Constructors, and the class must be a toplevel class. Then the concrete class is an enumerated type, and there may be no additional non-partial constructors of the class that are not listed in the of clause.

of larger | smaller | equal

of Root<Element> | Leaf<Element> | Branch<Element>

A type parameter with an of clause may specify multiple cases, as defined in §3.5.3 Generic type constraints.

An of clause may not contain:

If a generic enumerated type X has a case type C, then C must directly extend or satisfy an instantiation Y of X, and for each type parameter T of X and corresponding argument A of T given in Y, either:

Furthermore, if C is an instantiation of a generic type, then T may not occur twice in C.

For example, the following covariant enumerated type is legal:

interface List<out Element> 
        of Cons<Element> | nil { ... }

class Cons<out Element>(Element element) 
        satisfies List<Element> { ... }

object nil 
        satisfies List<Nothing> { ... }

As is the following contravariant enumerated type:

interface Consumer<in Event> 
        of Logger | Handler<Event> 
        given Event satisfies AbstractEvent { ... }

interface Logger 
        satisfies Consumer<AbstractEvent> { ... }

interface Handler<in Event> 
        satisfies Consumer<AbstractEvent> 
        given Event satisfies AbstractEvent { ... }

But the following enumerated type is not legal, since it is possible to choose a legal argument T of the type parameter Type of Expression, such that the case types StringLiteral and NumberLiteral aren't subtypes of the instantiation Expression<T>:

interface Expression<out Type>
        of Function<Type> | StringLiteral | NumberLiteral { ... }

interface Function<out Type> 
        satisfies Expression<Type> { ... }

interface StringLiteral
        satisfies Expression<String> { ... } //error String is not exactly Nothing

interface NumberLiteral
        satisfies Expression<Integer|Float> { ... } //error Integer|Float is not exactly Nothing

Two types are said to be disjoint if it is impossible to have a value that is an instance of both types. If X and Y are disjoint, then their intersection X&Y is the bottom type Nothing.

Two types X and Y are disjoint if either:

Furthermore, as a special case, the types X and Y are disjoint if:

A type parameter allows a declaration to be abstracted over a constrained set of types.

TypeParameter: Variance TypeName ("=" Type)?

Every type parameter has a name and a variance.

Variance: ("out" | "in")?

A type parameter may, optionally, have a default type argument. A type parameter with a default type argument must occur after every type parameter with no default type argument in the type parameter list.

The default type argument for a type parameter must satisfy the constraints on the type parameter.

A default type argument expression for a type parameter of a generic declaration may not involve:

Within the body of the schema it parameterizes, a type parameter is itself a type. The type parameter is a subtype of every upper bound of the type parameter. However, a class or interface may not extend or satisfy a type parameter.

<Key, out Item>

<in Message>

<out Element=Object>

<in Left, in Right, out Result>

A covariant type parameter may only appear in covariant positions of the parameterized schema. A contravariant type parameter may only appear in contravariant positions of the parameterized schema. An invariant type parameter may appear in any position.

Furthermore, a type with a contravariant type parameter may only appear in a covariant position in an extended type, satisfied type, case type, or upper bound type constraint.

To determine if a type expression occurs in a covariant or contravariant position, we first consider how the type occurs syntactically.

For a generic function we examine the return type of the function, which is a covariant position.

For a generic type schema we examine each shared member, along with extended/satisfied types and case types.

In a shared method declaration of the parameterized type schema:

In a shared attribute declaration that is neither variable nor late:

In a shared reference declaration that is either variable or late:

In a shared nested class declaration of the parameterized type schema:

In a shared nested interface declaration of the parameterized type schema:

For parameters of callable parameters, we first determine if the callable parameter itself is covariant or contravariant:

Then:

Finally, to determine if a type parameter that occurs as a type argument occurs in a covariant or contravariant position, we must consider the declared variance of the corresponding type parameter:

A parameterized method, class, or interface declaration may declare constraints upon ordinary type parameters using the given clause.

TypeConstraints: TypeConstraint+

There may be at most one given clause per type parameter.

TypeConstraint: "given" TypeName TypeConstraintInheritance

TypeConstraintInheritance: CaseTypes? SatisfiedTypes?

There are two different kinds of type constraint:

The types listed in an enumerated bound must be mutually disjoint, and each type must be a class or interface type.

A single given clause may specify multiple constraints on a certain type parameter. In particular, it may specify multiple upper bounds together with an enumerated bound. If multiple upper bounds are specified, at most one upper bound may be a class, and at most one upper bound may be a type parameter.

given Value satisfies Ordinal<Value> & Comparable<Value>

given Argument of String | Integer | Float

A type parameter is a subtype of its upper bounds.

class Holder<Value>(shared Value element) 
        extends Object()
        given Value satisfies Object {
    shared actual Boolean equals(Object that) {
        return if (is Holder<Value> that
            then element==that.element
            else false;
    }
    shared actual Integer hash => element.hash;
}

Every type parameter has an implicit upper bound of type Anything.

Characters uppercase<Characters>(Characters chars) 
       given Characters of String | Range<Character> { 
    switch (Characters)
    case (satisfies String) { 
        return chars.uppercased;
    }
    case (satisfies Range<Character>) { 
        return chars.first.uppercased..chars.last.uppercased;
    }
}

given T abstracts One|Two

given T(Object arg)

Every type argument has a variance:

It is illegal for both the type parameter and its type argument to have an explicit variance.

Given the schema of a generic declaration, we form the new schema by type argument substitution. Each type argument is substituted for every appearance of the corresponding type parameter in the schema of the generic declaration, including:

When a type argument A with no explicit variance annotation is substituted for a type parameter T, all occurrences of T in the schema of the generic declaration are replaced with A.

For type arguments with explicit variance of a type parameter T, substitution of the type argument depends upon whether an occurrence of T is a covariant or contravariant position in the schema of the generic declaration, as defined above in §3.5.2 Variance validation.

When a type argument out A explicitly marked covariant is substituted for a type parameter T:

When a type argument in A explicitly marked contravariant is substituted for a type parameter T:

A generic type constraint affects the type arguments that can be assigned to a type parameter in any type argument list belonging directly to:

A type constraint does not apply to any type argument list belonging to an applied type expression that occurs:

In locations where type constraints apply:

A type argument list conforms to a type parameter list if, for every type parameter in the list, either:

There must be at least as many type parameters as type arguments. There must be at least as many type arguments as type parameters without default values.

If a type argument list conforms to a type parameter list, the combination of the parameterized type together with the type argument list is itself a type, called an applied type. We also call the applied type an instantiation of the generic type.

For a generic type X, the instantiations Y and Z of X represent the same type if and only if for every type parameter P of X and corresponding type arguments A in Y and B in Z:

For a generic type G, and instantiations Y and Z of G, Y is a subtype of Z if and only if, for every type parameter T of G, and corresponding arguments A specified in Y and B specified in Z:

When a direct invocation expression, as defined by §6.6 Invocation expressions, does not explicitly specify type arguments, the type arguments are inferred from the argument expression types.

The types of the argument expressions and the declared types of the corresponding parameters determine an inferred lower bound or inferred upper bound for each type parameter.

If a list of argument expressions has types A1,A2,... and the corresponding list of parameters has declared types P1,P2,... then:

Given types A and P, we determine the inferred lower bound A on P for T according to the nature of A and P:

Where:

Given types A and P, we determine the inferred upper bound A on P for T according to the nature of A and P:

Where:

The inferred type argument to a covariant type parameter T of the generic declaration is:

The inferred type argument to a contravariant type parameter T of the generic declaration is:

An invariant type parameter T of the generic declaration is treated, for the purposes of type argument inference, as if it were covariant or contravariant, depending upon how it occurs in the types of parameters explicitly assigned arguments by the direct invocation, and, in the case of direct invocation of a generic function or class alias, upon how it occurs in the return type of the function or aliased type of the class alias.

An argument expression with no type occurring in a dynamic block, as defined in §5.3.5 Dynamic blocks, may cause type argument inference to fail. When combining bounds using union, any constituent bound with no type results in a bound with no type. When combining bounds using intersection, any constituent bound with no type is eliminated. If the resulting inferred upper or lower bound has no type, type argument inference is impossible for the type argument, and type arguments must be specified explicitly.

Finally, when every type parameter Pi has been assigned an inferred type argument Ai, each inferred type argument is adjusted according to the upper bound type constraints on Pi. The final inferred type argument is the intersection of Ai with every type Vj formed by substituting all Ais for their corresponding Pis in an upper bound Uj of Pi.

If the inferred type argument does not satisfy the generic type constraints on T, a compilation error results.

Consider the following invocation:

[Element+] prepend<Element>(Element head, Element[] sequence) { ... }
value result = prepend(null, {"hello", "world"});

The inferred type of Element is the union type String?.

Now consider:

class Bag<out Element>(Element* elements) {
    shared Bag<ExtraElement> with<ExtraElement>(ExtraElement* elements) 
            given ExtraElement abstracts Element { ... }
}
Bag<String> bag = Bag("hello", "world");
value biggerBag = bag.with(1, 2, 5.0);

The inferred type of ExtraElement is the union type Integer|Float|String.

Finally consider:

interface Delegate<in Value> { ... }
class Consumer<in Value>(Delegate<Value>* delegates) { ... }
Delegate<String> delegate1 = ... ;
Delegate<Object> delegate2 = ... ; 
value consumer = Consumer(delegate1, delegate2);

The inferred type of Value is Consumer<String>.

An inferred type argument never involves an anonymous class, as defined in §4.5.7 Anonymous classes. When an inferred type would involve an anonymous class type, the anonymous class is replaced by the intersection of the class type it extends with all interface types it satisfies.

For a generic type G, inheritance produces subtypes with inherited instantiations of the generic type.

A pair of type arguments A and B are considered:

If a class or interface type X has the inherited instantiations V and W of some generic type Y, then:

Therefore, if a type X is a subtype of the instantiations V and W of some generic type Y, then either:

Finally, the following identities result from principal instantiation inheritance. For any generic type X<T>, and for any given types A and B:

If a type X is a subtype of some instantiation V of a generic type Y, then, as a result of the principal instantiation inheritance restriction, we can form a unique instantiation of Y that is a subtype of every instantiation of Y to which X is assignable. We call this type the principal instantiation of Y for X.

We compute principal instantiations by making use of the identities observed above in §3.2.3 Union types, §3.2.4 Intersection types, and §3.7.3 Principal instantiation inheritance. For any generic type X:

A class or interface may declare an actual member with the same name as a member that it inherits from a supertype if the supertype member is declared formal or default. Then we say that the first member refines the second member, and it must obey restrictions defined in §4.5.6 Member class refinement, §4.7.8 Method refinement, or §4.8.7 Attribute refinement.

A declaration may not be annotated both formal and default.

If a declaration is annotated formal, default, or actual then it must also be annotated shared.

For any class or interface X, and for every declared or inherited member of X that is not refined by some other declared or inherited member of X, and for every other member declared or inherited by X that directly or indirectly refines a declaration that the first member itself directly or indirectly refines, the principal instantiation for X of the type that declares the first member must be a subtype of the principal instantiation for X of the type that declares the second member.

A type declaration that directly occurs in the body of another type is called a nested type. If a nested type is annotated shared, it may be used in a type expression outside the body in which it is declared, if and only if it occurs as a qualified type, as specified in §3.2.7 Type expressions.

The qualified types X.U and Y.V are exactly the same types if and only if U is exactly the same type as V, and in the case that this type is a member of a generic type Z, then the principal instantiation of Z for X is exactly the same type as the principal instantiation of Z for Y.

A qualified type X.U is a subtype of a qualified type Y.V if U is a subtype of V, and in the case that V is a member of a generic type Z, then X is a subtype of the principal instantiation of Z for Y.

Given a member declared by Y, and a declaration that refines it, we can construct a refined realization of the member or nested type:

Given an unqualified reference, as defined in §5.1.7 Unqualified reference resolution, to a declaration, and, in the case of a generic declaration, a list of type arguments for the type parameters of the declaration, we can construct an unqualified realization of the declaration:

Given a qualified reference, as defined in §5.1.8 Qualified reference resolution, with a qualifying type X, to a member or nested type declared by Y, and, in the case of a generic member or generic nested type, a list of type arguments for the type parameters of the member, we can construct a qualified realization of the member or nested type:

If, for any given qualified or unqualified reference, it is impossible to form the principal instantiation of the type that declares the referenced declaration, due to the hole described above in §3.7.4 Principal instantiation of a supertype, it is impossible to form a realization, and the reference to the declaration is illegal.

A toplevel declaration defines a type—a class or interface—or a type alias, or a function or value.

Declaration: FunctionValueDeclaration | TypeDeclaration | ParameterDeclaration

FunctionValueDeclaration: FunctionDeclaration | ValueDeclaration | SetterDeclaration

TypeDeclaration: ClassDeclaration | ObjectDeclaration | InterfaceDeclaration | TypeAliasDeclaration

A toplevel declaration is not polymorphic and so may not be annotated formal, default, or actual.

Most toplevel declarations contain nested declarations.

Nested declarations are often mixed together with executable statements.

Each compilation unit belongs to exactly one package. Every toplevel declaration of the compilation unit also belongs directly to this package. The package is identified by the location of the text file on the file system, relative to a root source directory, as defined in §9.2 Source layout.

A package is a namespace. A full package name is a period-separated list of identifiers.

FullPackageName: PackageName ("." PackageName)*

There is also a default package whose name is empty. It is impossible to import declarations from this package.

Every package belongs to exactly one module, as specified in §9.3 Module architecture. The default package belongs to the default module.

An import element that specifies a type name imports the toplevel type with that name from the imported package or type.

ImportTypeElement: TypeAlias? TypeName ImportElements?

The specified name must be the name of a type declaration belonging to the imported package or type.

import ceylon.collection { MutableSet, MutableList, MutableMap }

The import element may be followed by a list of nested import elements:

An import element that specifies the name of an anonymous class, as defined in §4.5.7 Anonymous classes, imports the anonymous class with that name from the imported package or type.

ImportObjectElement: FunctionValueAlias? MemberName ImportElements?

The specified name must be the name of an anonymous class declaration belonging to the imported package or type.

import ceylon.file { home, current }

The import element may be followed by a list of nested import elements:

An import element that specifies a function or value name imports the toplevel function or value with that name from the imported package or type.

ImportFunctionValueElement: FunctionValueAlias? MemberName

The specified name must be the name of a function or value declaration belonging to the imported package or type.

import ceylon.math.float { sqrt, e, pi }

The optional alias clause in a fully-explicit import allows resolution of cross-namespace declaration name collisions.

TypeAlias: TypeName "="

FunctionValueAlias: MemberName "="

An alias assigns a different name to the imported declaration, or to a member of the imported declaration. This name is visible within the compilation unit, block, class body, or interface body in which the import statement occurs.

import java.util { JavaMap = Map }

import my.math { fib = fibonnacciNumber }

import java.lang { 
    Math { sin, cos, ln=log }, 
    System { sysprops=properties },
    Char=Character { upper=toUpperCase, lower=toLowerCase, char=charValue } 
}

The elipsis ... acts as a wildcard in import statements. An import statement that specifies a wildcard imports every toplevel declaration of the imported package, except for any declaration whose name collides with the name of a declaration contained directly in the compilation unit, block, class body, or interface body in which the import statement occurs.

ImportWildcard: "..."

An import statement may specify a list of alias imports followed by a wildcard. In this case, the alias imports are imported with the specified names, and all other toplevel declarations are imported with their declared names.

import ceylon.collection { ... }

import my.math { fib = fibonnacciNumber, ... }

Inside a compilation unit which imports a declaration, the declaration may be referred to, as specified in §5.1.7 Unqualified reference resolution and §5.1.8 Qualified reference resolution, by its imported name:

An import element may not result in an imported name that is the same as the name of a declaration directly contained in the compilation unit, block, class body, or interface body in which the import element occurs.

Two import elements occurring in the same compilation unit, block, class body, or interface body, which import into the toplevel namespace of the compilation unit, or into a local scope, may not result in the same imported name.

Two nested import elements belonging to the same import element may not result in the same imported name.

A parameter list is a list of parameter declarations and of names of parameters declared in the body of the class or function to which the parameter list belongs. A parameter list may include, optionally:

In a parameter list, defaulted parameters, if any, must occur after required parameters, if any. The variadic parameter, if any, must occur last.

Parameters: "(" ( (Required ",")* ( Required | (Defaulted ",")* (Defaulted | Variadic) ) )? ")"

Every parameter list has a type, which captures the types of the individual parameters in the list, whether they are defaulted, and whether the last parameter is variadic. This type is always an subtype of Anything[]. The type of an empty parameter list with no parameters is [].

A parameter may not be annotated formal, but it may be annotated default.

A required parameter is a value or callable parameter without a default argument.

A required parameter in a parameter list may be a parameter declaration, or the name of a non-variadic parameter declared in the body of the function or class.

Required: ValueParameter | CallableParameter | MemberName

Required parameters must occur before any other parameters in the parameter list.

A defaulted parameter is a value or callable parameter that specifies an expression that produces a default argument. A defaulted parameter may be either:

Defaulted: ValueParameter Specifier | CallableParameter LazySpecifier | MemberName Specifier

The = and => specifiers are used throughout the language. In a parameter list they are used to specify a default argument.

Specifier: "=" Expression

LazySpecifier: "=>" Expression

The default argument expression may involve other non-variable parameters declared earlier in the parameter list or lists. It may not involve parameters declared later in the parameter list or lists. It may not involve variable parameters of the parameter list.

The default argument expression may not involve an assignment, compound assignment, increment, or decrement operator.

Defaulted parameters must occur after required parameters in the parameter list.

(Product product, Integer quantity=1, Price pricing(Product p) => p.price)

A parameter of a method or class annotated actual may not specify a default argument. Instead, it inherits the default argument, if any, of the corresponding parameter of the method it refines.

If two parameter lists are almost identical, differing only in that the first parameter of one list is defaulted, and the first parameter of the second list is required, and P is the the type of the second parameter list, then the type of the first parameter list is []|P.

A value parameter is a reference, as specified in §4.8.1 References, that is named or defined in a parameter list. Like any other value declaration, it has a name, type, and, optionally, annotations.

ValueParameter: Annotations ValueParameterPrefix MemberName

ValueParameterPrefix: Type | "value" | "dynamic"

A value parameter may be declared using the keyword dynamic in place of the parameter type, indicating that it is a partially typed declaration. Such a parameter has no type.

In general, a value parameter must have an explicit type declaration, and may not be declared with the keyword value.

As a special exception, if a parameter of an anonymous function is declared with the keyword value, then the type of the parameter must be inferable, according to §6.4.1 Anonymous function parameter type inference.

If a value parameter x has type X, and a parameter list has type P with the principal instantiation Sequential<Y>, then the type of a new parameter list formed by prepending x to the first parameter list is:

The default argument expression, if any, for a callable parameter is specified using an ordinary = specifier. The type of the default argument expression must be assignable to the declared type of the value parameter.

(String label, Anything() onClick)

({Value*} values, Comparison(Value,Value) by)

A callable parameter is a function, as specified in §4.7 Functions, named or defined in a parameter list. Like any other function declaration, it has a name, type, one or more parameter lists, and, optionally, annotations.

CallableParameter: Annotations CallableParameterPrefix MemberName Parameters+

CallableParameterPrefix: Type | "void" | "dynamic"

A callable parameter may be declared using the keyword dynamic in place of the return type, indicating that it is a partially typed declaration. Such a parameter has no return type.

If a callable parameter f has callable type X(*A), as specified below in §4.7.1 Callable type of a function, and a parameter list has type P with the principal instantiation Sequential<Y>, then the type of a new parameter list formed by prepending f to the first parameter list is:

The default argument expression, if any, for a callable parameter is specified using a lazy => specifier. The type of the default argument expression must be assignable to the return type of the callable parameter.

(String label, void onClick())

({Value*} values, Comparison by(Value x, Value y))

A variadic parameter is a value parameter that accepts multiple arguments:

VariadicParameter: Annotations VariadicParameterPrefix MemberName

VariadicParameterPrefix: UnionType ("*" | "+")

A variadic parameter in a parameter list may be a variadic parameter declaration, or the name of a variadic parameter declared in the body of the function or class.

Variadic: VariadicParameter | MemberName

The variadic parameter must be the last parameter in a parameter list. A variadic parameter may not have a default argument. A variadic parameter declared T+ may not occur in a parameter list with defaulted parameters.

(Name name, Organization? org=null, Address* addresses)

(Float+ floats)

The type of a parameter list containing just a variadic parameter of type T* is [T*] The type of a parameter list containing just a variadic parameter of type T+ is [T+].

The body of an interface consists purely of declarations. The following constructs may not occur sequentially in the body of an interface:

Within an interface body, a super reference is any occurrence of the expression super, unless it also occurs in the body of a nested class or interface declaration. A statement or declaration contained in the interface body may not:

An interface may satisfy any number of other interfaces, as defined in §3.3.3 Satisfaction.

shared interface List<Element>
        satisfies Collection<Element> & Correspondence<Integer,Element>
        given Element satisfies Object {
    ...
}

Every type listed in the satisfies clause must be an interface. An interface may not satisfy the same interface twice (not even with distinct type arguments).

The interface is a subtype of every type listed in the satisfies clause. The interface is also a subtype of the type Object defined in ceylon.language.

An interface inherits all members (methods, attributes and member types) of every supertype. That is, every member of every supertype of the interface is also a member of the interface. Furthermore, the interface inherits all nested types (interfaces and abstract classes) of every supertype.

The schema of the inherited members is formed by substituting type arguments specified in the satisfies clause.

An interface that satisfies a nested interface must be a member of the type that declares the nested interface or of a subtype of the type that declares the nested interface.

A user-defined interface may not satisfy the interface Callable defined in ceylon.language nor directly satisfy the interface ConstrainedAnnotation defined in ceylon.language.

A toplevel or nested interface may be annotated sealed and is called a sealed interface.

An interface annotated sealed may not be satisfied by a class or interface outside the module in which it is defined.

An interface declaration may enumerate a list of cases of the interface, as defined in §3.4.2 Cases.

shared interface Node<Element> 
            of Root<Element> | Branch<Element> | Leaf<Element> { ... }

The cases may be interfaces, classes, or toplevel anonymous classes. A case may be an abstract class. Each case must be a direct subtype of the interface type. An interface may not be a case of itself. An interface declaration may not list the same case twice.

If an interface has an of clause, then every interface or class which directly inherits the interface must occur as exactly one of the enumerated cases of the interface. Furthermore, any interface or class which indirectly inherits the interface must inherit exactly one of the enumerated cases of the interface.

An interface alias is an interface declaration which specifies another type.

TypeSpecifier: "=>" Type

The specified type must be an interface type, that is, a reference to an interface with no type parameters or an instantiation of a generic interface, and is called the aliased type.

An interface alias simply assigns an alternative name to the aliased type. A reference to the alias may occur anywhere a reference to an interface may occur.

shared interface PeopleByName => Map<String,Person>;

interface Compare<Value> => Comparison(Value,Value);

If the aliased interface is a parameterized type, the aliased type must explicitly specify type arguments.

A class or interface may satisfy an interface alias, in which case, the class or interface inherits the aliased interface type.

Interface aliases are not reified types. The metamodel reference for an interface alias type—for example, PeopleByName—returns the metamodel object for the aliased interface—in this case, Map<String,Person>, as specified in §8.1.2 Type argument reification.

A dynamic interface is an interface declared with the keyword dynamic. Dynamic interfaces may be used to model the type of objects defined in dynamically typed native code.

Every declaration nested inside a dynamic interface must be declared formal. A dynamic interface may not satisfy any interface that is not also a dynamic interface.

Within a dynamic block, defined in §5.3.5 Dynamic blocks, assignment of a value with no Ceylon type to a dynamic interface type does not result in an AssertionError, as defined in §8.3.6 Dynamic type checking. Instead, the value is coerced to the dynamic interface type.

The callable type of a class with an initializer parameter list captures the type and initializer parameter types of the class. The callable type is T(*P), where T is the applied type formed by the class with its own type parameters as type arguments, and P is the type of the initializer parameter list of the class.

The callable type of a class with a default constructor is the callable type of the default constructor.

A class with no initializer parameter list and no default constructor does not have a callable type.

An abstract class is not callable, except from the extends clause of a subclass, or the class specifier of a class alias.

The initial part of the body of a class is called the initializer of the class and contains a mix of declarations, statements, and control structures. The initializer is executed every time the class is instantiated. If the class does not have an initializer parameter list, the initializer section may include one or more constructor declarations, as defined in §4.9 Constructors.

A class initializer is responsible for initializing the state of the new instance of the class, before a reference to the new instance is available to clients.

shared abstract class Point() {
    shared formal Float x;
    shared formal Float y;
}

shared class DiagonalPoint(Float distance) 
        extends Point() {
    
    value d = distance / 2^0.5;
    x => d;
    y => d;
    
    "must have correct distance from origin" 
    assert (x^2 + y^2 == distance^2);
    
}

shared object origin 
        extends Point() {
    x => 0.0;
    y => 0.0;
}

Within a class initializer, a self reference to the instance being initialized is:

A statement or declaration contained in the initializer of a class may not evaluate an attribute, invoke a method, or instantiate a member class upon the instance being initialized, including upon a self reference to the instance being initialized, if the attribute, method, or member class:

A member class contained in the initializer of a class may not extend a member or nested class of an interface or superclass of the class.

Furthermore, a statement or declaration contained in the initializer of a class may not:

Nor may the class pass a self reference to the instance being initialized as an argument of its own extends clause expression, if any.

As a special exception to these rules, a statement contained in an initializer may assign a self-reference to the instance being initialized to a reference annotated late.

For example, the following code fragments are not legal:

class Graph() {
    OpenList<Node> nodes = ArrayList<Node>();
    class Node() {
        nodes.add(this);    //error: self reference in initializer
    }
}

class Graph() {
    class Node() {}
    Node createNode() {
        Node node = Node();
        nodes.add(node);    //error: forward reference in initializer
        return node;
    }
    OpenList<Node> nodes = ArrayList<Node>();
}

But this code fragment is legal:

class Graph() {
    OpenList<Node> nodes = ArrayList<Node>();
    Node createNode() {
        Node node = Node();
        nodes.add(node);
        return node;
    }
    class Node() {}
}

The remainder of the body of the class consists purely of declarations, similar to the body of an interface. The following constructs may not occur sequentially in the declaration section:

However, the declarations in this second section may freely use this and super, and may invoke any method, evaluate any attribute, or instantiate any member class of the class or its superclasses.

Within the declaration section of a class body, a super reference is any occurrence of the expression super, unless it also occurs in the body of a nested class or interface declaration. A statement or declaration contained in the declaration section of a class body may not:

A class may extend another class, as defined in §3.3.2 Extension.

shared class Customer(Name name, Organization? org = null) 
        extends Person(name, org) { 
    ... 
}

The class is a subtype of the type specified by the extends clause. If a class does not explicitly specify a superclass using extends, its superclass is the class Basic defined in ceylon.language.

A class may satisfy any number of interfaces, as defined in §3.3.3 Satisfaction.

class Token() 
        extends Datetime()
        satisfies Comparable<Token> & Identifier {
    ... 
}

The class is a subtype of every type listed in the satisfies clause. A class may not satisfy the same interface twice (not even with distinct type arguments).

A class inherits all members (methods, attributes, and member types) of every supertype. That is, every member of every supertype of the class is also a member of the class. Furthermore, the class inherits all nested types (interfaces and abstract classes) of every supertype.

Unless the class is declared abstract or formal, the class:

The schema of the inherited members is formed by substituting type arguments specified in the extends or satisfies clause.

A subclass with an initializer parameter list must pass arguments to each superclass initialization parameter or callable constructor parameter in the extends clause. A subclass with no initializer parameter list may not pass arguments in the extends clause.

shared class SpecialKey1()
        extends Key( SpecialLock() ) {
    ...
}

shared class SpecialKey2(Lock lock) 
        extends Key(lock) {
    ...
}

A subclass of a nested class must be a member of the type that declares the nested class or of a subtype of the type that declares the nested class. A class that satisfies a nested interface must be a member of the type that declares the nested interface or of a subtype of the type that declares the nested interface.

A user-defined class may not satisfy the interface Callable defined in ceylon.language nor directly satisfy the interface ConstrainedAnnotation defined in ceylon.language.

A toplevel or nested class may be annotated abstract and is called an abstract class.

A toplevel or nested class may be annotated final and is called a final class.

A toplevel or nested class may be annotated sealed and is called a sealed class.

If a class annotated shared is a member of a containing class or interface, then the class may be annotated formal and is called a formal member class, or, sometimes, an abstract member class.

An abstract class or formal member class may have formal members.

An abstract class may not be instantiated.

A formal member class may be instantiated.

A class which is not annotated formal or abstract is called a concrete class.

A concrete class may not have formal members.

A class annotated final must be a concrete class.

A class annotated final may not have default members.

If a concrete class annotated shared is a member of a containing class or interface, then the class may be annotated default and is called a default member class.

A toplevel class may not be annotated formal or default.

An un-shared class may not be annotated formal or default.

A class annotated sealed may not be instantiated or extended outside the module in which it is defined.

A class with no parameter list may not be annotated sealed.

A member class annotated sealed formal must belong to a sealed class or interface.

shared formal class Buffer(Character...) 
        satisfies Sequence<Character>;

Member class refinement is a unique feature of Ceylon, akin to the "factory method" pattern of many other languages.

A member class of a subtype refines a member class of a supertype if the member class of the supertype is shared and the two classes have the same name. The first class is called the refining class, and the second class is called the refined class.

Then, given the refined realization of the class it refines, as defined in §3.7.7 Realizations, and, after substituting the type parameters of the refined class for the type parameters of the refining class in the schema of the refining class, the refining class must:

Furthermore:

If a member class is annotated actual, it must refine some member class of a supertype.

A member class may not, directly or indirectly, refine two different member classes not themselves annotated actual.

Then instantiation of the member class is polymorphic, and the actual subtype instantiated depends upon the concrete type of the containing class instance.

shared abstract class Reader() {
    shared formal class Buffer(Character* chars) 
            satisfies Character[] {}
    ...
}

shared class FileReader(File file) 
        extends Reader() {
    shared actual class Buffer(Character* chars) 
            extends super.Buffer(chars) {
        ...
    }
    ...
}

All of the above rules apply equally to member classes which are aliases.

shared abstract class Reader() {
    shared formal class Buffer(Character* chars) => AbstractBuffer(*chars);
    ...
}

shared class FileReader(File file) 
        extends Reader() {
    shared actual class Buffer(Character* chars) => FileBuffer(*chars);
    ...
}

An object or anonymous class declaration is a compact way to define a class with a single value constructor, together with a getter aliasing this value constructor.

ObjectDeclaration: Annotations ObjectHeader ClassBody

An object has an initial lowercase identifier. An object declaration does not specify parameters or type parameters.

ObjectHeader: "object" MemberName ObjectInheritance

ObjectInheritance: ExtendedType? SatisfiedTypes?

An object declaration specifies the name of the value and the schema, supertypes, and implementation of the class. It does not explicitly specify a type name. Instead, the type name is formed by prefixing the value name with \I, turning it into an initial uppercase identifier, as specified by §2.3 Identifiers and keywords.

An object class:

Therefore, members of an object may not be declared formal nor default.

The body of the object declaration is the body of the class.

This class never appears in types inferred by local declaration type inference or generic type argument inference. Instead, occurrences of the class are replaced with the intersection of the extended type with all satisfied types.

An object value is a getter, as defined in §4.8.2 Getters, that simply returns a reference to the value constructor of the class. The value:

Therefore, the object may not be annotated default nor formal.

Annotations applying to an object declaration are considered annotations of the object value, and are accessible via its ValueDeclaration, as defined in §6.10 Reference expressions.

The following declaration:

shared my object red extends Color('FF0000') {
     string => "Red";
}

Is exactly equivalent to:

shared final class \Ired of red extends Color {
     shared new red extends Color('FF0000') {}
     string => "Red";
}

shared my \Ired red => \Ired.red;

Where \Ired is the type name assigned by the compiler.

shared object sql {
    shared String escape(String string) { ... }
}

...

String escapedSearchString = sql.escape(searchString);

A class declaration may enumerate a list of cases of the class, as defined in §3.4.2 Cases.

The cases listed in the of clause must exhaust every means by which an instance of the class may be instantiated:

shared abstract class Boolean() 
        of true | false {}
        
shared object true extends Boolean() { string => "true"; }
shared object false extends Boolean() { string => "false"; }

shared abstract class Node<Element>(String name) 
        of Branch<Element> | Leaf<Element> { ... }
        
shared class Leaf<Element>(String name, Element element) 
        extends Node<Element>(name) { ... }
        
shared class Branch<Element>(String name, Node<Element> left, Node<Element> right) 
        extends Node<Element>(name) { ... }

shared class Status of enabled | disabled {
    shared actual String string;
    shared new enabled { string => "enabled"; }
    shared new disabled { string => "disabled"; }
}

A non-abstract class with an initializer parameter list or a callable constructor may not specify an of clause.

A non-abstract, non-toplevel class may not specify an of clause.

A class declaration may not list the same case twice.

shared abstract class Boolean(shared actual String string) 
        of object true ("true") | 
           object false ("false") {}

A class alias is a class declaration which specifies a reference to a class or callable constructor of a class, followed by a positional argument list, as defined in §6.6.7 Positional argument lists.

ClassSpecifier: "=>" (Extension | Construction)

The specification of the class or callable constructor is treated as a value expression, as in §3.3.2 Extension. The type of this value expression must be a class type, that is, a reference to a class with no type parameters or an instantiation of a generic class, and is called the aliased type.

A class alias simply assigns an alternative name to the aliased type. A reference to the alias may occur anywhere a reference to a class may occur.

shared class People(Person* people) => ArrayList<Person>(*people);

class Named<Value>(String name, Value val) 
        given Value satisfies Object
        => Entry<String,Value>(name, val);

Arguments to the initializer parameters of the aliased class must be specified.

If the aliased class is a parameterized type, the aliased type must explicitly specify type arguments.

The type arguments may not be inferred from the initializer arguments.

If a toplevel class alias or un-shared class alias aliases an abstract class, the alias must be annotated abstract, and it may not be directly instantiated.

If a shared class alias nested inside the body of a class or interface aliases an abstract class, the alias must be annotated abstract or formal. If it is annotated formal, it is considered a member class of the containing class or interface. If it is annotated abstract, it is considered an abstract nested class of the containing class or interface.

A class alias may not alias a partial constructor. A shared class alias may not alias an un-shared constructor.

A class may extend a class alias, in which case, the class inherits the aliased class type.

Class aliases are not reified types. The metamodel reference for a class alias type—for example, People—returns the metamodel object for the aliased class—in this case, ArrayList<Person>, as specified in §8.1.2 Type argument reification.

The callable type of a function captures the return type and parameter types of the function.

A function implementation may be a block.

shared Integer add(Integer x, Integer y) {
    return x + y;
}

shared void printAll(Object* objects) {
    for (obj in objects) {
        print(obj);
    }
}

shared void addEntry(Key->Item entry) {
    map.put(entry.key,entry.item);
}

shared Set<Element> singleton<Element>(Element element) 
        given Element satisfies Comparable<Element> {
    return TreeSet { element };
}

Alternatively, a function implementation may be a lazy specifier, that is, an expression specified using =>. The type of the specified expression must be assignable to the return type of the function. In the case of a function declared void, the expression must be a legal statement, as defined by §5.3.1 Expression statements.

shared Integer add(Integer x, Integer y) => x + y;

shared void addEntry(Key->Item entry) => map.put(entry.key,entry.item);

shared Set<Element> singleton<Element>(Element element) 
            given Element satisfies Comparable<Element>
        => TreeSet { element };

A non-void, un-shared function with a block or lazy specifier may be declared using the keyword function in place of the explicit return type declaration. Then the function return type is inferred:

This function has inferred return type Integer.

function add(Integer x, Integer y) => x + y;

This function has inferred return type Float|Integer.

function unit(Boolean floating) {
    if (floating) {
        return 1.0;
    }
    else {
        return 1;
    }
}

This function has inferred return type Nothing.

function die() {
    throw;
}

The declaration of a function may be separated from the specification of its implementation. If a function declaration does not have a lazy specifier, or a block, and is not annotated formal, and is not a parameter, it is a forward-declared function.

A forward-declared function may later be specified using a specification statement, as defined in §5.3.3 Specification statements. The specification statement for a forward-declared function may be:

Comparison order(String x, String y);
if (reverseOrder) {
    order(String x, String y) => y<=>x;
}
else {
    order(String x, String y) => x<=>y;
}

Comparison format(Integer x);
switch (base)
case (decimal) {
    format = (Integer i) => i.string; 
}
case (binary) {
    format = formatBin;
}
case (hexadecimal) {
    format = formatHex;
}

Every forward-declared function must explicitly specify a type. It may not be declared using the keyword function.

A toplevel function may not be forward-declared. A method of an interface may not be forward-declared. A method annotated default may not be forward-declared.

If a shared method is forward-declared, its implementation must be definitely specified by all conditional paths in the class initializer.

A function may declare multiple lists of parameters. A function with more than one parameter list returns instances of Callable in ceylon.language when invoked. Every function with multiple parameter lists is exactly equivalent to a function with a single parameter list that returns an anonymous function.

This function declaration:

Boolean greaterThan<Element>(Element val)(Element element)
        given Element satisfies Comparable<Element> => 
                element>val;

is equivalent to the following:

Boolean(Element) greaterThan<Element>(Element val)
        given Element satisfies Comparable<Element> => 
                (Element element) => element>val;

For a function with n parameter lists, there are n-1 inferred anonymous functions. The ith inferred function:

Then the original function returns the first inferred anonymous function.

This method declaration:

function fullName(String firstName)(String middleName)(String lastName)
        => firstName + " " + middleName + " " + lastName;

Is equivalent to:

function fullName(String firstName) =>
        (String middleName) =>
                (String lastName) =>
                        firstName + " " + middleName + " " + lastName;

If a function declaration does not have a lazy specifier, or a block, and is annotated shared, and is a method of either:

then the function declaration may be annotated formal, and is called a formal method, or, sometimes, an abstract method.

shared formal Item? get(Key key);

A method which is not annotated formal is called a concrete method.

If a concrete method is annotated shared, and is a member of a class or interface, then it may be annotated default and is called a default method.

shared default void writeLine(String line) {
    write(line);
    write("\n");
}

A method annotated formal may not specify an implementation (a lazy specifier, or a block).

A method annotated default must specify an implementation (a lazy specifier, or a block), and may not be forward-declared.

Every formal method must explicitly specify a type. It may not be declared using the keyword function.

A toplevel method may not be annotated formal or default.

An un-shared method may not be annotated formal or default.

Methods may be refined, just like in other object-oriented languages.

A method of a subtype refines a method of a supertype if the method of the supertype is shared and the two methods have the same name. The first method is called the refining method, and the second method is called the refined method.

Then, given the refined realization of the method it refines, as defined in §3.7.7 Realizations, and, after substituting the type parameters of the refined method for the type parameters of the refining method in the schema of the refining method, the refining method must:

Furthermore:

If a method is annotated actual, it must refine some method defined by a supertype.

A method may not, directly or indirectly, refine two different methods not themselves annotated actual.

Then invocation of the method is polymorphic, and the actual method invoked depends upon the concrete type of the class instance.

shared abstract class AbstractSquareRooter() {
    shared formal Float squareRoot(Float x);
}

class ConcreteSquareRooter()
        extends AbstractSquareRooter() {
    shared actual Float squareRoot(Float x) => x^0.5;
}

Alternatively, a subtype may refine a method using a specification statement, as defined in §5.3.3 Specification statements. The specification statement must satisfy the requirements of §4.7.5 Forward declaration of functions above for specification of a forward-declared function.

class ConcreteSquareRooter()
        extends AbstractSquareRooter() {
    squareRoot(Float x) => x^0.5;
}

The lifecycle and scope of the persistent value of a reference depends upon where the reference declaration occurs:

The persistent value of a reference may be specified or initialized as part of the declaration of the reference, or via a later specification statement, as defined in §5.3.3 Specification statements, or assignment expression, as defined in §6.8 Operators, or, if it is a parameter, by an argument to an invocation expression, as defined in §6.6 Invocation expressions.

A reference annotated variable has a persistent value that can be assigned multiple times. A reference not annotated variable has a persistent value that can be specified exactly once and not subsequently modified.

variable Integer count = 0;

shared Decimal pi = calculatePi();

shared Integer[] evenDigits = [0,2,4,6,8];

A reference declaration may have a specifier which specifies its persistent value or, in the case of a variable reference, its initial persistent value. The type of the specified expression must be assignable to the type of the reference.

If the specified expression has no type, and the declaration occurs within a dynamic block, then the specification is not type-checked at compile time.

If a reference is a parameter, it must not specify a persistent value.

A reference belonging to a class may be annotated late, in which case the initializer of the class is not required to initialize its persistent value. Furthermore, a self-reference to an instance being initialized may be assigned to the reference.

A reference annotated late may not be initialized or assigned a value by the class initializer. A parameter may not be annotated late. A reference not belonging to a class may not be annotated late.

If a class declares or inherits a variable reference, it must (directly or indirectly) extend the class Basic defined in ceylon.language.

A getter implementation may be a block.

shared Float total {
    variable Float sum = 0.0;
    for (li in lineItems) {
        sum += li.amount;
    }
    return sum;
}

Every conditional execution path of the block must end in a return directive that specifies an expression assignable to the type of the value, or in a throw directive, as specified in §5.3.6 Definite return.

Alternatively, a getter implementation may be a lazy specifier, that is, an expression specified using =>. The type of the specified expression must be assignable to the type of the value.

Name name => Name(firstName, initial, lastName);

A setter defines how the value of a getter is assigned.

SetterDeclaration: Annotations "assign" MemberName (Block | LazySpecifier)

The name specified in a setter declaration must be the name of a matching getter that directly occurs earlier in the body containing the setter declaration. If a getter has a setter, we say that the value is variable.

Within the body of the setter, a value reference to the getter evaluates to the value being assigned.

A setter implementation may be a block. The block may not contain a return directive that specifies an expression.

shared String name { return join(firstName, lastName); }
assign name { firstName=first(name); lastName=last(name); }

Alternatively, a setter implementation may be a lazy specifier. The specified expression must be a legal statement.

shared String name => join(n[0], n[1]);
assign name => n = [first(name), last(name)];

A setter may not be annotated shared, default or actual. The visibility and refinement modifiers of an attribute with a setter are specified by annotating the matching getter.

An un-shared value with a block, specifier, or lazy specifier may be declared using the keyword value in place of the explicit type declaration. Then the value's type is inferred:

value names = List<String>();

variable value count = 0;

value name => Name(firstName, initial, lastName);

The declaration of a reference may be separated from the specification or initialization of its persistent value. The declaration of a getter may be separated from the specification of its implementation. If a value declaration does not have a specifier, lazy specifier, or a block, and is not annotated formal, it is a forward-declared value.

A forward-declared value may later be specified using a specification statement, as defined in §5.3.3 Specification statements.

String greeting;
switch (language)
case (en) {
    greeting = "Hello";
}
case (es) {
    greeting = "Hola";
}
else {
    throw LanguageNotSupported();
}
print(greeting);

Every forward-declared value must explicitly specify a type. It may not be declared using the keyword value.

A toplevel value may not be forward-declared. An attribute of an interface may not be forward-declared. An attribute annotated default may not be forward-declared.

A forward-declared getter may not have a setter.

If a shared value is forward-declared, its implementation must be definitely specified by all conditional paths in the class initializer.

If a value declaration does not have a specifier, lazy specifier, or a block, and is annotated shared, and is a member of either:

then the value declaration may be annotated formal, and is called a formal attribute, or, sometimes, an abstract attribute.

shared formal variable String firstName;

An attribute which is not annotated formal is called a concrete attribute.

If a concrete attribute is annotated shared, and is a member of a class or interface, then it may be annotated default and is called a default attribute.

shared default String greeting = "Hello";

An attribute annotated formal may not specify an implementation (a specifier, lazy specifier, or a block). Nor may there be a setter for a formal attribute.

An attribute annotated default must specify an implementation (a specifier, lazy specifier, or a block), and may not be forward-declared.

Every formal attribute must explicitly specify a type. It may not be declared using the keyword function.

A toplevel attribute may not be annotated formal or default.

An un-shared attribute may not be annotated formal or default.

Ceylon allows attributes to be refined, just like methods. This helps eliminate the need for Java-style getter and setter methods.

Any non-variable attribute may be refined by a reference or getter. A variable attribute may be refined by a variable refernce or by a getter and setter pair.

An attribute of a subtype refines an attribute of a supertype if the attribute of the supertype is shared and the two attributes have the same name. The first attribute is called the refining attribute, and the second attribute is called the refined attribute.

Then, given the refined realization of the attribute it refines, as defined in §3.7.7 Realizations, the refining attribute must:

Furthermore:

If an attribute is annotated actual, it must refine some attribute defined by a supertype.

An attribute may not, directly or indirectly, refine two different attributes not themselves annotated actual.

A non-variable attribute may be refined by a variable attribute.

Then evaluation and assignment of the attribute is polymorphic, and the actual attribute evaluated or assigned depends upon the concrete type of the class instance.

shared abstract class AbstractPi() {
    shared formal Float pi;
}

class ConcretePi() 
        extends AbstractPi() {
    shared actual Float pi = calculatePi();
}

Alternatively, a subtype may refine an attribute using a specification statement, as defined in §5.3.3 Specification statements. The specification statement must satisfy the requirements of §4.8.5 Forward declaration of values above for specification of a forward-declared attribute.

class ConcretePi() 
        extends AbstractPi() {
    pi = calculatePi();
}

For a callable constructor, the callable type of the constructor captures the type of the class, and parameter types of the constructor. The callable type is T(*P), where T is the applied type formed by the class with its own type parameters as type arguments, and P is the type of the parameter list of the constructor.

A constructor of an abstract class is not callable, except from the extends clause of a subclass, or the class specifier of a class alias.

A partial constructor is not callable, except from the extends clause of another constructor of the same class.

The type of a value constructor is simply T, where T is the class to which it belongs.

A callable constructor annotated abstract is called a partial constructor.

A partial constructor may not be annotated shared.

A default constructor may not be annotated abstract.

A value constructor may not be annotated abstract.

Every constructor of any class which does not directly extend Basic defined in ceylon.language must explicitly delegate, as defined in §3.3.2 Extension, to either:

If the constructor of a class which directly extends Basic does not have an extends clause, the constructor implicitly delegates to the initializer of Basic.

A program element is contained within the namespace of a declaration if either:

The namespace of a declaration may not contain a second declaration with the same name. For example, the following is illegal:

function fun(Float number) {
    if (number<0.0) {
        Float number = 1.0; //error
        ...
    }
    ...
}

As an exception to this rule, the namespace of a declaration annotated native may contain a second declaration with the same name if:

A class or interface may not inherit a declaration with the same name as a declaration it contains unless either:

A class or interface may not inherit two declarations with the same name unless either:

The scope of a declaration is governed by the body or package in which it occurs. A declaration is in scope at a program element if and only if either:

Where:

Furthermore:

And finally, there are special rules for annotation lists, defined in §7.1.1 Annotation lists:

Classes, interfaces, functions, values, aliases, and type parameters have names. Occurrence of a name in code implies a hard dependency from the code in which the name occurs to the schema of the named declaration. We say that a class, interface, value, function, alias, or type parameter is visible to a certain program element if its name may occur in the code that belongs to that program element.

The visibility of a declaration depends upon where it occurs, and upon whether it is annotated shared. A toplevel or member declaration may be annotated shared:

A type parameter or a declaration that occurs directly inside a block (the body of a function, getter, setter, or control structure) may not be annotated shared.

We say that a type is visible to a certain program element if it is formed from references to classes, interfaces, type parameters, and type aliases whose declarations are visible to the program element. For shared declarations:

If two declarations with the same name or imported name, as defined in §4.2.6 Imported name, are both in scope at a certain program element, then one declaration may hide the other declaration.

For example, the following code is legal:

class Person(name) {
    String name;
    shared String lowerCaseName {
        String name = this.name.lowercased;
        return name;
    }
}

As is this code:

class Point(x, y) {
    shared Float x; 
    shared Float y;
}

class Complex(Float x, Float y=0.0) 
        extends Point(x, y) {}

When a member of a class is hidden by a nested declaration, the member may be accessed via the self reference this, defined in §6.3.1 this, or via the outer instance reference outer, defined in §6.3.2 outer.

shared class Item(name) {
    variable String name;
    shared void changeName(String name) {
        this.name = name;
    }
}

class Catalog(name) {
    shared String name;
    class Schema(name) {
        shared String name;
        Catalog catalog => outer;
        String catalogName => outer.name;
        class Table(name) {
            shared String name;
            Schema schema => outer;
            String schemaName => outer.name;
            String catalogName => catalog.name;
        }
    }
}

When a toplevel declaration of a package is hidden by another declaration, the toplevel declaration may be accessed via the containing package reference package, as defined in §5.1.7 Unqualified reference resolution.

Integer n => 0;
Integer f(Integer n) => n+package.n;

A declaration may be in scope at a program element, but not referenceable at the program element. A declaration is referenceable at a program element if the declaration is in scope at the program element and either:

Note that these rules have very different consequences for:

Declarations that occurs in a block or class initializer section are interspersed with procedural code that initializes references. Therefore, a program element in a block or initializer may not refer to a declaration that occurs later in the block or class body. This restriction does not apply to declarations that occur in an interface body or class declaration section. Nor does it apply to toplevel declarations, which are not considered to have a well-defined order.

The following toplevel function declarations, belonging to the same package, are legal:

Float x => y;

Float y => x;

This code is not legal, since the body of a function is an ordinary block:

Float->Float xy() {
    Float x => y;  //error: y is not referenceable
    Float y => x;
    return x->y;
}

This code is not legal, since all three statements occur in the initializer section of the class body:

class Point() {
    Float x => y;  //error: y is not referenceable
    Float y => x;
    Float->Float xy = x->y;
}

However, this code is legal, since the statements occur in the declaration section of the class body:

class Point() {
    Float x => y;
    Float y => x;
}

Likewise, this code is legal, since the statements occur in an interface body:

interface Point {
    Float x => y;
    Float y => x;
}

If a declaration is annotation restricted, and a program element does not occur in either:

then the declaration is not referenceable at the program element.

A value declared using the keyword value or a function declared using the keyword function may be in scope at a program element, but its type may not be inferable, as defined by §3.2.9 Type inference, from the point of view of that program element.

The type of a value or function declared using the keyword value or function is inferable to a program element if the declaration is in scope at the program element and the program element occurs within the lexical scope of the declaration.

For any other declaration, including any declaration which explicitly specifies its type, the type is considered inferable to a program element if the declaration is in scope at the program element.

The following code is not legal:

interface Point {
    value x => y;  //error: type of y is not inferable
    value y => x;
}

However, this code is legal:

interface Point {
    value x => y;
    Float y => x;
}

An unqualified reference is:

If a program element contains an unqualified reference:

There are two exceptions to the above rules.

Then the reference is to this unique unhidden declaration, and:

As a special exception to the above, if there is no declaration with the given name or imported name in scope at the program element and the program element occurs inside a dynamic block, then the unqualified reference does not refer to any statically typed declaration.

If an unqualified reference refers to a member declaration of a type, then there is a unique inheriting or declaring class or interface for the unqualified reference, that is, the unique class or interface in whose body the unqualified reference occurs, and which declares or inherits the member declaration, and for which the member is not hidden at the program element where the unqualified reference occurs.

A qualified reference is:

Every qualified reference has a qualifying type:

A qualified reference may not have Nothing as the qualifying type.

If a program element contains a qualified reference:

Then the reference is to the unique member or nested class. If the program element is contained in the body of a class or interface, and the member declaration directly occurs in the body of the class or interface, and the qualified reference is a value reference or callable reference, and the receiver expression is a self reference to the instance being initialized, then:

As a special exception to the above, if the program element occurs inside a dynamic block, and the the receiver expression has no type, then the qualified reference does not refer to any statically typed declaration.

A variable is a streamlined form of reference declaration, as defined by §4.8.1 References.

TypedVariable: Type MemberName

In most cases, the explicit type be omitted.

Variable: (Type | "value")? MemberName

If the explicit type is missing from the declaration, the type of the variable is inferred, according to rules that depend upon the control structure to which the variable belongs.

A variable declared by a destructuring statement is a reference scoped to the body in which the destructuring statement occurs.

A variable declared by an assertion is a reference scoped to the body in which the assert statement occurs.

A variable declared by a control structure is a reference scoped to the block that immediately follows the variable declaration:

An expression whose type is an instantiation of Sequential, Sequence, Tuple, or Entry may be assigned to a pattern. The type of an expression assigned to a pattern is called the patterned type.

Patterns are formed from:

Pattern: Variable | TuplePattern | EntryPattern

A pattern variable is just a variable, as defined above, that occurs in a pattern.

If the variable has an explicit type, then the patterned type must be assignable to this type. Otherwise, the type of the variable is inferred to be the patterned type.

A variadic pattern variable is indicated with an asterisk.

VariadicVariable: UnionType? "*" MemberName

Variadic pattern variables only occur in tuple patterns.

A tuple pattern comprises a list of element patterns, ending in, optionally, a variadic pattern variable called a variadic element pattern. Tuple patterns are enclosed in brackets.

TuplePattern: "[" (Pattern ",")* (Pattern | VariadicVariable) "]"

The patterned type must be an instantiation of the type Tuple, Sequential, or Sequence in ceylon.language. Then:

value [x, y, z] = [1.0, 2.0, 0.0];

value [first, *rest] = sequence;

An entry pattern comprises a key pattern, followed by an item pattern.

EntryPattern: KeyOrItemPattern "->" KeyOrItemPattern

KeyOrItemPattern: Variable | TuplePattern

The patterned type must be an instantiation K->V of the type Entry in ceylon.language. Then:

value name->[lat,long] = observatory;

Only certain expressions are valid statements:

ExpressionStatement: ( Assignment | IncrementOrDecrement | Invocation ) ";"

For example:

x += 1;

x++;

print("Hello");

Main(process.arguments);

A control directive statement ends execution of the current block and forces the flow of execution to resume in some outer scope. They may only occur as the lexically last statement of a block.

There are four control directives:

Directive: (Return | Throw | Break | Continue) ";"

For example:

throw Exception();

return x+y;

break;

continue;

The return directive must sequentially occur in the body of a function, getter, setter, or class initializer. In the case of a setter, class initializer, or void function, no expression may be specified. In the case of a getter or non-void function, an expression must be specified. The expression type must be assignable to the return type of the function or the type of the value. When the directive is executed, the expression is evaluated to determine the return value of the function or getter.

Return: "return" Expression?

If the specified expression has no type, or if the function or getter has no type, and the directive occurs within a dynamic block, then the directive is not type-checked at compile time.

The break directive must sequentially occur in the body of a loop.

Break: "break"

The continue directive must sequentially occur in the body of a loop.

Continue: "continue"

A throw directive may appear anywhere and may specify an expression, whose type must be a subtype of type Throwable defined in ceylon.language. When the directive is executed, the expression is evaluated and the resulting exception is thrown. If no expression is specified, the directive is equivalent to throw Exception().

Throw: "throw" Expression?

If the specified expression has no type, and the directive occurs within a dynamic block, then the directive is not type-checked at compile time.

A specification statement may specify or initialize the persistent value of a forward-declared reference, or specify the implementation of a forward-declared getter or function.

Specification: ValueSpecification | LazySpecification

The persistent value of a forward-declared reference or the implementation of a forward-declared function may be specified by a value specification statement. The value specification statement consists of an unqualified value reference, or a qualified value reference where the receiver expression is this, and an ordinary = specifier. The value reference must refer to a declaration which sequentially occurs earlier in the body in which the specification statement occurs.

ValueSpecification: ("this" ".")? MemberName Specifier ";"

The type of the specified expression must be assignable to the type of the reference, or to the callable type of the function.

If the specified expression has no type, or if the reference or function has no type, and the specification occurs within a dynamic block, then the specification is not type-checked at compile time.

String greeting;
if (exists name) {
    greeting = "hello ``name``";
}
else {
    greeting = "hello world";
}

String process(String input);
if (normalize) {
    process = String.normalized;
}
else {
    process = (String s) => s;
}

The implementation of forward-declared getter or function may be specified using a lazy specification statement. The specification statement consists of either:

The value reference or callable reference must refer to a declaration which sequentially occurs earlier in the body in which the specification statement occurs.

A callable reference followed by a parameter list is itself considered a callable reference, called a parameterized reference. If the parameter list has type P then the callable reference must have the exact type R(*P) for some type R. Then the type of the parameterized reference is R.

ParameterizedReference: ("this" ".")? MemberName Parameters+

Thus, the specification statement consists of a parameterized reference followed by a lazy specifier.

LazySpecification: (MemberName | ParameterizedReference) LazySpecifier ";"

The type of the specified expression must be assignable to the type of the parameterized reference, or to the type of the value reference.

String greeting;
if (exists name) {
    greeting => "hello ``name``";
}
else {
    greeting => "hello world";
}

String process(String input);
if (normalize) {
    process(String input) => input.normalized;
}
else {
    process(String s) => s;
}

A destructuring statement assigns an expression to a pattern, as defined above in §5.2.2 Patterns.

Destructure: "value" (TuplePattern | EntryPattern) Specifier ";"

The type of the specified expression is the patterned type of the tuple or entry pattern.

A dynamic block allows interoperation with dynamically typed native code.

Dynamic: "dynamic" Block

Inside a dynamic block an expression may have no type, as specified in Chapter 6, Expressions.

An expression with no type:

Furthermore:

These situations result in dynamic type checking, as defined in §8.3.6 Dynamic type checking, since the usual static type checks are impossible.

A sequence of statements may definitely return.

The body of a non-void method or getter must definitely return.

A body may not contain an additional statement, control structure, or declaration following a sequence of statements that definitely returns. Such a statement, control structure, or declaration is considered unreachable.

A sequence of statements may definitely initialize a forward-declared declaration.

If a function or value declaration is referenceable at a certain statement or declaration, it may additionally be considered definitely initialized at that statement or declaration.

If a function declaration is definitely initialized at a certain statement or declaration if it is referenceable at that statement or declaration and: