Syntax diagrams

Syntax diagrams for the whole Liberty Eiffel language.

All items in alphabetical order: Assignment, Assertion, Binary_operator, Call, Check, Class_declaration, Class_name, Class_type, Clients, Comment, Compound, Create_expression, Create_instruction, Creation_clause, Current, Debug, Digit, Digit_sequence, Entity_declaration_list, Expression, Feature_clause, Feature_declaration, Feature_name, Formal_generic_list, If_then_else, Infix_operator, Inspect, Instruction, Loop, Manifest_notation, Manifest_string, New_export_item, Notes, Parent_list, Prefix_operator, Result, Routine, Routine_body, Type, Unary_operator, Unqualified_call, Writable.

---

Notes

A Notes section might be used at the beginning and end of a file to define notes on a class (e. g. for documentation, version management, license information, etc.). They have no influence on the execution semantics.

 "Notes" {Notes = "note" Note_list.
Note_list = Note_entry ";" [Note_list] .
Note_entry = Note_name Note_values .
Note_name = Identifier ":".
Note_values = Note_item "," [Note_value].
Note_item = Identifier | Manifest_constant.
}

Comment

A comment is made of one or more line segments, each beginning with two consecutive dash characters -- and extending to the end of the line:

 "Comment" { Comment =  "--" {String} {Newline}.}

Inside the comment, the convention to denote Eiffel entities (i.e. variables, arguments or other features as well) is to enclose the corresponding name between ` and ' as follows:

-- Here `my_variable' is supposed to be bla bla bla ...

This convention allows some tools like Eiffeldoc or Short or emacs as well to use a different character font or color to emphasize the fact that my_variable refers to some existing entity of the Eiffel code. Previous convention must not be used for class names which are to be typed normally in comments as:

-- My FOO clas is bla bla bla bla ...

Also note that an URL inside the comment is also made automatically clickable by Eiffeldoc. This way, each time some class of our library needs a long explanation that does not reasonably fit in the Eiffel comment itself, we just add the URL into the comment. As an example, the following comment displayed by Eiffeldoc would bring you back here :

-- See also http://wiki.liberty-eiffel.org/index.php/Syntax_diagrams#Comment

Class declaration

Related items: Assertion, Class_name, Creation_clause, Feature_clause, Formal_generic_list, Manifest_string, Parent_list.

Formal generic list

To be used only when the class is generic. The Identifier is not the name of an existing class, but usually, just a simple upper case letter (see also Class_name). The Class_type part, when used, is the generic constraint.

Related items: Class_type, Identifier.

Parent list

Related items: Feature_name, New_export_item.

New export item

Related items: Class_name.

Creation clause

Related items: Feature_name, Comment.

Feature clause

Related items: Clients, Comment, Feature_declaration.

Clients

Related items: Class_name.

Feature declaration

'is' is now optional, and the choice after 'is' now could include 'attribute' diagram requires update...

Where the Manifest_constant can only be selected in the following set: { BOOLEAN, CHARACTER, INTEGER_8, INTEGER_16, INTEGER_32, INTEGER, INTEGER_64, REAL_32, REAL_64, REAL, REAL_80, REAL_128, REAL_EXTENDED, STRING, UNICODE_STRING }. See the file SmartEiffel/tutorial/manifest_notation.e to have a detailed explaination plus examples about all available notations for constants.

Related items: Entity_declaration_list, Feature_name, Routine, Type.

Routine

Related items: Assertion, Compound, Entity_declaration_list, Feature_name, Manifest_string.

Routine body

 "Routine body" {
   Routine_body  =  ( "deferred" | "do" compound | "once" compound | 
                      "external_string" Manifest_string "Alias" Manifest_string ).
}

Related items: Compound, Manifest_string.

Entity declaration list

This notation is used for local variable list declaration as well as for formal argument list of routines.

Related items: Identifier, Type.

Type

Related items: Class_type, Formal_generic_name, Identifier.

Class name

A class name must use only upper case letters plus the '_' underscore character. A class name must start with a letter, an upper case letter as all other letters used in that name. The convention is to not use two consecutive '_' underscore characters, nor to end a class name by an underscore character (by convention we keep simple names with a trailing underscore character, like O_ as a formal parameter type of a generic type). Some examples of valid class names: ARRAY, ANY, LINKED_LIST.

Class type

A class type does not use anchored types.

Related items: Class_name.

Digit

 "Digit" {
Digit = ("0"|"1"|"..."|"9"|"a"|"b"|"..."|"f"|"A"|"B"|"..."|"F"|"_" ). }

Digit_sequence

 "Digit_sequence" {
Digit_sequence = Digit {Digit}.
}

Binary operator

Following operators can be redefined in your own class:

 "Binary operator" {
   Binary_operator = (("+"|"-"|"*"|"/"|"//"|"\\")| 
                      ("<"|">"|"<="|">=")|
                      ("and"|"or"|"xor")| 
                      ("and then"|"or else"|"implies")).}

Infix operator

 "Infix operator" {
   Infix_operator = (Binary_operator|Free_operator).}

Related items: Binary_operator, Free_operator.

Prefix operator

 "Prefix operator" {
   Prefix_operator = (Unary_operator|Free_operator).}

Related items: Unary_operator, Free_operator.

Unary operator

 "Unary operator" {
   Unary_operator = ("+"|"-"|"not").}

Free operator

"Free_Operator"  { Free_Operator = ( "+" | "-" | "*" | "/" | "\" | "=" |
                   "<" | ">" | "@" | "#" | "|" |"&" | "~") { Free_Operator }.}

Writable

What we call Writable here is what can be for example on the left-hand-side of the := assignment operator. You have only 3 choices:

• the name of one local variable of the enclosing method,
• the Result variable used to prepare the return value of the enclosing function,
• the name of one writable attribute of Current.

Feature name

Related items: Infix_operator, Prefix_operator.

Compound

Related items: Instruction.

Instruction

Related items: Assignment, Call, Check, Create_instruction, Debug, If_then_else, Inspect, Loop, Retry.

Assignment

Related items: Expression, Writable.

Procedure call or function call

Related items: Expression, Unqualified_call.

Loop: the only construct for iterative computation

Related items: Assertion, Compound, Expression.

If then else statement

Related items: Assertion, Compound, Expression.

Inspect: the multi-branch selection statement

The order in which the when branches are written does not influence the effect of an inspect instruction.

Also note that the Expression can only be of type INTEGER, CHARACTER or STRING. All used Constants must have the same type as the type of Expression. Furthermore, all constants must be statically computable in order to allow the compiler to check for disjunction of various when parts (only one Compound is ever selected).

By writing no else part at all (no keyword else used), you state that Expression does NEVER take a value not covered by the inspect constants. If your expectations prove wrong, the effect is to trigger a run-time error when the code is compiled with appropriate options, in boost mode the behavior is unspecified. Therefore, it is suggested to always write an else clause as defensive programming.

Related items: Expression, Compound.

Create instruction

 "Create_Instruction" {
Create_Instruction = create ["{"Type"}"] writable ["." Unqualified_call].
}

See also the Create_expression variant form.

Related items: Type, Unqualified_call, Writable.

Check list

A check instruction helps express a property that you believe will be satisfied whenever system execution reaches this instruction.

 "Check" {
Check = "check" Assertion "end".
}

Related items: Assertion.

Debug only compound

The Debug instruction serves to request the conditional execution of a certain sequence of Instructions, depending on a compilation option.

Related items: Compound, Instruction.

Retry for exceptions

The retry instruction is only for exceptions purpose and the retry statement is valid only when used inside the rescue clause of some enclosing routine. The form of this instruction is just:

 "Retry" {Retry = "retry".}

The effect of a the retry instruction is to restart nearly from scratch the execution of the enclosing routine. Actually, even the require assertion of the routine is re-checked. Only local variables (including Result) are not reset to the default value.

Expression

Related items: Binary_operator, Call, Current, Manifest_notation, Result, Type, Unary_operator, Writable.

Current is an expression

And this Expression denotes the Current object. The notation is simply:

 "Current" { Current = "current". } 

The Result variable

The Result variable is valid only inside the definition of some function. The notation is simply:

 "Result" { Result = "result". }

The purpose of the Result variable is to prepare the result of the enclosing function. Actually, the Result variable behave like an ordinary local variable. Like a local variable, the Result variable is automatically initialized with the default value of the corresponding type. Using the Result variable does not makes you returns from the enclosing function: it is just like a local variable.

Manifest notation

Manifest notation includes:

• True and False for BOOLEAN,
• 'A', 'B', 'C', ... for CHARACTER
• 1, 2, 3, ... for INTEGER
• ...

See the file SmartEiffel/tutorial/manifest_notation.e to have a detailed explaination plus examples about all available notations for constants of types: BOOLEAN, CHARACTER, INTEGER, REAL, STRING and UNICODE_STRING.

Furthermore, the file , SmartEiffel/tutorial/manifest_notation.e also explain how to create explicitely objects of types ARRAY, FAST_ARRAY, LINKED_LIST, DICTIONARY, SET, etc., ...

Manifest string

 "Manifest string" { Manifest_string = '"' string '"' . } 

Create expression

 "Create expression" {
     Create_expression =  create "{" type "}"  [ "." Unqualified_call ].
}

See also the Create_instruction variant form.

Related items: Type, Unqualified_call.

Unqualified call

Where Identifier_1 is the name of the feature which is called. So Identifier_1 can be the name of some attribute only when no parenthesis are used just after Identifier_1. When parenthesis are used after Identifier_1, it must be a routine name.

The Identifier_2 used together with the $ character indicates that the address of Identifier_2 is passed to the callee. Thus, Identifier_2 can be either some local variable name or the name of some attribute of Current. This $ facility is not supposed to be used in your every day life, but for some external interface facility.

Related items: Expression.

Assertion

Here, the Identifier is just a name given to the assertion. This optional name which is supposed to explain the Expression is printed too in case of error at run-time. The syntax to use for the Identifier is the same used for local variables, attributes or argument names: only lower case letters plus the _ underscore character.

The Expression must be of type BOOLEAN. When the Expression is replaced by a Comment (which is bad news) this Comment is considered equivalent to True. Finally, the semicolon used to separate the next Assertion can be considered as the and operator.

Related items: Comment, Expression.