Skip to main content
Jump to: navigation, search

EDT:Language Overview

Revision as of 17:47, 14 October 2011 by (Talk | contribs)

This overview introduces the EGL language as defined in EGL Core and as extended by Eclipse IDE for the EGL Developer. Reference details are in the EDT help system, which is made available when you install a download from the following site:


In many ways, EGL is like other programming languages. It includes familiar constructs such as loops and transfers of control. It is built on a set of types, each of which defines the operations that are available for each value of the type. Last, it involves a process for validating source code and for converting the source code into a less abstract form, closer to the runtime need.

EGL is special in its reliance on stereotypes, which are declarations used by the software that transforms the source code to another form such as Java or JavaScript.

Stereotypes offer simplicity. First, they ensure that the output created for a source-code element such as "Handler" includes details for a particular use; for example, to be runnable on a full-page web browser. The developer who writes a customized Handler element and declares the appropriate stereotype does not need to know a lot about a browser to write the code. He can rely on the pre-tested logic that an EGL JavaScript generator creates automatically. 

Second, stereotypes provide a way to extend the language. The creation of a new kind of stereotype enables an existing source-code element to have an alternative use. For example, a future stereotype might allow a developer to write a custom Handler element and then to create output for a mobile device that runs under the Android operating system. This alternative option requires that the extender create Java classes that supplement existing logic. 

The mechanism for using stereotypes is a characteristic of EGL Core, which includes the basic rules of EGL syntax. Specific stereotypes are a characteristic of an EGL extension, the first of which is Eclipse IDE for the EGL Developer.

EGL Syntax

EGL source code is a sequence of tokens, which are the smallest units of meaning. The EGL tokens are categorized as follows:

  • Keywords, which are the the EGL reserved words; for example, Record. 
  • Identifiers. which are the names of types, functions, variables, and constants. An example is myCarCount, which is a variable name.
  • Literals, which are fixed values of a given type. Examples are the integer 5, the string “yes!”, and the Boolean value TRUE.
  • Operators, which are symbols that affect a value. The value, or operand, is on the left or right of an operator. For example, the < operator is part of a condition that tests whether the operand on the left has a lesser value than the operand on the right.
  • Special characters, which are punctuation marks that divide tokens, as necessary for the parsing done by the EGL compiler. For example, parentheses (( )) might surround a condition such as myVariable < yourVariable

At a more composite level, the language includes the following constructs:

  • Type definitions, which are sequences of tokens that define a type.
  • Expressions, which are sequences of tokens that express unnamed instances. For example, 4 + 5 might be assigned to a variable, but is itself a value of type INT.
  • Statements, which is an instruction that causes work to occur at run time or that organizes code at development and transformation time:
    • The runtime work might be variable declaration, data manipulation, logic invocation, output to a user interface or persistent data storage, and so forth.
    • The organization work might include assigning types to packages, importing types from other packages, and enabling a shortcut for referencing identifiers that are in libraries.
Most statements begin with an EGL keyword. For example, the following statement writes “yes!” to the standard output:  SysLib.writeStdOut("yes!");
  • Set-values blocks, which are code areas that set annotations and field values and are delimited by curly brackets ({}), as shown in the following declaration:
myCarCount NumberOfCars { InputRequired = yes };
The example set-values block declares an InputRequired annotation for the myCarCount variable.

Set-values blocks are used in various ways in type definitions, statements, expressions, and other set-values blocks.

EGL types and values

The next sections move from general comments to a review of EGL native types, custom types, classifiers, annotations, and stereotypes.

General comments on types and values

In general usage, a type such as integer or string defines a set of values and a set of operations that can be applied to those values. For example, integers are whole numbers that can be added, subtracted, and so forth; and the number 5 is a value of that type.

The meaning is much the same in EGL, where every value is “of a type.” The type defines the structure of the value and the set of operations that can be applied to the value.

Types can be categorized in different ways, and we initially distinguish between reference and value types:  

  • A reference type defines an object, which is a value in a memory area that was separately allocated to hold the value. The object is referenced from some logic and is an instance of the type. In this case, the words "value," "object," and "instance" are interchangeable.
  • A value type defines a value that is embedded in an object.

field declaration is a coded statement that declares a value in a memory area. If the value is based on a reference type, the memory area either represents a null or holds an address that points to the value. If the value is based on a value type, the memory area contains the value itself.

A field declaration typically includes an identifier that names the memory area. If the code that embeds the field declaration is allowed to update the area, the identifier is a variable. If the update is disallowed, the identifier is a constant. Later in this overview is a field declaration that does not name a memory area at all. Such a field declaration is said to be anonymous.

Consider the following field declarations:

   // variable declaration
   NumberOfCars INT;    
   // constant declaration
   const MINIMUMNUMBER INT = 2; 

The type is each case is INT, which is a value type for four-byte integers. The first statement declares a value variable, the second declares a value constant.

For a second example, you might declare a list of five integers by coding a statement like one of these:

   // variable declaration
   NumberOfVehicles INT[5];

   // constant declaration
   const MINIMUMNUMBERS INT[5] = [1,2,3,4,5];

The type in this case is INT List or INT[], which is a reference type. The first statement declares a reference variable, which means that you can assign a different list to NumberOfVehicles later. Incidentally, you can also change the values inside the list and can change the number of elements.

The second statement declares a reference constant, which means that you cannot assign a different list to MINIMUMNUMBERS. However, even in this case, you can alter the values inside the list and can change the number of elements.

The behavior is consistent because each declaration in the second example identifies a memory area that contains an address of a second memory area. The constant is only constant in the sense that the area identified as MINIMUMNUMBERS must always contain the same address, which refers to the same list. The following, subsequent assignment is not valid even though the values are the same:

   // An invalid assignment
   MINIMUMNUMBERS = [1,2,3,4,5]; 

EGL native types

EGL Core defines a set of native types, which are implemented only by extensions such as Eclipse IDE for EGL Developers. The most elemental are the simple types. They have no sub-fields and can be categorized as follows:

  • Boolean, which is the basis of a field that contains the logical true or false.
  • Character types 
  • Timestamp types
  • Large object types
  • Numeric types

The following native types are also defined in EGL Core and implemented by Eclipse IDE for the EGL Developer: 

  • ANY, which is the basis of an instance that can reference a value of any type.
  • Dictionary type, which is the basis of a dictionary. A dictionary is composed of key-value
    pairs that can be increased or decreased in number and otherwise updated at run time.
  • List types, each of which is the basis of a list. A list is a dynamic array: an ordered sequence of elements that can be increased or decreased in number and otherwise updated at run time.

Custom types and EGL classifiers

EGL provides a variety of classifiers, each of which is a kind of type. The capabilities of a classifier are made available to your code in various situations; most often, when you define a custom type that is based on a classifier.

Characteristics of custom types

Depending on the classifier, a custom type can have some or all of the following characteristics:

  • A header, which is always required. The header includes the classifier name; the name of the custom type; and, in some cases, a stereotype.
  • The end keyword, which is the last detail in the type definition.
  • A set of members:
    • Fields, each of which is based on a native or custom type.
    • Functions, each of which is a logical unit that is equivalent to a function or method in another language. EGL functions do not embed other functions.
    • Constructors, each of which is a logical unit that creates an instance of a reference type.

The members in a custom type are typically accessible in the same type. However, if you declare a member to be private, the member is protected from external access; it can be accessed only within the same type. If you do not declare a member to be private, it is said to be public.

Kinds of classifiers

The next table lists the classifier provided in EGL Core. 

Kinds of classifiers
       Name                              Purpose                        
Class To provide the Any, Dictionary, and List types.
DataItem To alias a native or custom type.
Delegate To define a type that identifies a kind of function. The related variable is like a function pointer in C language.
Enumeration To define a type that holds a collection of named values. The value of the related variable is one of those values. 
ExternalType To define a type that identifies non-EGL code. The related variable provides access to the code.
Handler To define a type that includes all the possible kinds of members. The related variable either defines a general purpose object or allows for interaction with a user interface technology.
Interface To define a type that identifies the characteristics of functions in a service. The related variable provides access to the service.
Library To define a static type that contains fields and functions that are local to other EGL logic. The fields retain values across requesters.
Program To define a static type that has a single entry point.
Record To define a type that includes fields.
Service To define a static type that has multiple entry points and that might be accessed locally or remotely.  The type also can be the basis of a variable that provides access to the logic from other EGL code.

To extend a capability, an extender makes an additional stereotype available for use with an existing classifier. The list of classifiers is a fixed aspect of the language.


When you write EGL source code, you set annotations. They are values used by some aspect of EGL technology; in most cases, by the EGL compiler. 

Annotations help ensure that your EGL-created output reflects your intent. You can set them when you define custom types; when you declare variables and constants; when you code a subset of EGL statements; and, in some cases, when you declare functions.

For example, when you declare a field in a user-interface form, you might set a YES value in the InputRequired annotation. That setting causes the EGL generator to store a detail in the generated output, and the detail ensures that the user can submit the form only if the specified field has content.

Annotation types

An annotation represents an area of memory and is based on an EGL type. To understand these points, consider the following declaration:

myCarCount NumberOfCars { InputRequired = yes }; 

That code has effects at two different stages:

  • It declares the myCarCount variable. The appropriate declaration statement is generated into the output code, and the related instance is available at run time. The type of the variable is NumberOfCars, which is an alias of type INT. Here is the alias, or data item:
   NumberOfCars INT
  • The example also identifies an instance that is available at transformation time. The type of that instance is InputRequired.

    Here is the EGL Record type:
Record InputRequired type Annotation
   value Boolean;

All annotations are based on one or another EGL Record type.

Annotation syntax

The InputRequired declaration in the earlier source code did not set the value field explicitly. The InputRequired = Yes assignment is a shorthand form of the following code:

@InputRequired { value = yes }

The at sign (@) indicates that you are declaring an annotation, and the characters "InputRequired" indicate that the annotation is based on the InputRequired Record type. The next characters then assign content to the fields in the annotation. The braces ({ and }) represents a set values block, as described here:

A shorthand form such as InputRequired = Yes is available whenever the Record type for the annotation has a single field, regardless of the name of that field. If an annotation has multiple fields, only the long form of the declaration is valid, as in the following example:

@AnotherAnnotation { field01 = "test", field02 = 5 }

An annotation can be based on a Record type that has no fields. In that case, the mere presence of the annotation is meaningful to the EGL system code, and only the at sign (@) is required. Here is an example declaration:


In many cases, you can declare multiple annotations, one separated from the next by a comma. For example, the following code declares the InputRequired and DisplayName annotations: 

myCarCount NumberOfCars {
   InputRequired = yes, 
   DisplayName   = "Number of cars: " };

Annotation overrides

You can declare an annotation when you define a type, and then override the annotation when you declare a variable that is based on the type.

Here is a data item with two annotations:

   NumberOfCars { 
      InputRequired = no, 
      DisplayName = "Number of cars: "}

The following variable declaration overrides the previous value of the InputRequired annotation:

myCarCount NumberOfCars { InputRequired = yes }; 

If a data item or part includes several annotations and a few are overridden in a variable declaration, the annotations that were not overridden are still in effect. In the previous example, the myCarCount variable is associated with both the InputRequired and DisplayName annotations.

The ability to set multiple annotations is particularly important for data items. For example, a data item might be defined with annotations that are meaningful for user interface and for accessing a relational database. The benefit of being able to specify multiple annotations is that you can retain data items in a library and use those data items for many purposes. When you use a data item to declare a variable for one purpose such as database access, the annotations relevant to other purposes such as user interface have no effect.

Most annotations have a relatively small effect. For example, the InputRequired annotation specifies whether a field in a user-interface form is generated in one way or another. But a stereotype is an annotation that affects a series of decisions; the effect is greater.


A stereotype is an annotation that you set to communicate a major decision to the EGL compiler. In response to the annotation, the compiler responds in accordance with a pattern that differs from one stereotype to another.

For example, you might want to display a web page that responds as follows to a button click: by changing the button text from "Toggle on" to "Toggle off" or from "Toggle off" to "Toggle on".  The logic is in the following handler, which includes a declaration for the RUIHandler stereotype:

Handler MyHandler type RUIhandler{
   initialUI =[myButton],
   onConstructionFunction = start}
   myButton DojoButton{ 
      onClick ::= myButton_onClick }; 
   function start()
      myButton.text = "Toggle on";

   function myButton_onClick(event Event in)
      if (myButton.text == "Toggle on")
         myButton.text = "Toggle off";
         myButton.text = "Toggle on"; 

You might want to provide the same capability on a mobile device that runs on the Android operating system. In this case, an extender might provide a pair of constructs...  ??

Handler MyHandler type WindowHandler
   { createLayout = true, contentView = } 


   myButton DojoButton{ 
      text = "Toggle on", 
      onClick ::= myButton_onClick }; 

   function myButton_onClick(event Event in)
      if (myButton.text == "Toggle on") 
         myButton.text = "Toggle off"; 
         myButton.text = "Toggle on"; 

[ Explain ]

To see that a stereotype is a kind of annotation, compare the following, equivalent outlines for the MyHandler handler:

Handler MyHandler type RUIHandler
                      initialUI =[myButton],
                      onConstructionFunction = start

   // handler members are here 


Handler MyHandler { @RUIHandler 
                       initialUI = [myButton],
                       onConstructionFunction = start

   // handler members are here


Although the second, longer form is rarely used, the at sign (@) again declares a value used by an EGL compiler. In this case, the declaration is based on the Record type named RUIHandler, which includes several fields:

Record RUIHandler type Annotation
      targets = [ElementKind.handlerPart],
      @Stereotype {defaultSuperType=View},
      validationProxy = 

         // split onto two lines for better display
   onConstructionFunction FunctionMemberRef;
   includeFile String;
   cssFile String;
   title String;
   theme String; 

The RUIHandler Record type declares three annotations:

  • targets indicates the custom types for which the stereotype applies. The term "part" is sometimes used in place of the term "custom type," and the ElementKind.handlerPart value indicates that a Handler type can be annotated with a value of type RUIHandler. The absence of any other ElementKind value indicates that no other kind of custom type can be annotated in the same way.
  • @Stereotype indicates that the Record type is defining a stereotype. Fields in the View supertype are available to the Handler type being stereotyped. In particular, the custom Handler type has access to the initialUI field, which lists the widgets for initial display on the web page.
  • validationProxy identifies a Java class that validates the stereotype value with which the custom Handler type is annotated.

The RUIHandler Record type also declares a set of fields, which are available to any custom type that declares a RUIHandler stereotype. The earlier code identified only one of those fields: onConstructionFunction, which references a constructor that runs initially, before the user accesses the web page. These fields are properly called annotation fields or, more specifically, stereotype fields.   

If you annotate a custom type with a stereotype, and if the custom type can include fields of its own, the stereotype can declare an annotation of type MemberAnnotations. The purpose is to list the annotations that can be appled to each field of the custom type. Here is an example of such an annotation:

Record ExampleStereotype type Annotation
   targets = [ElementKind.recordPart],
   memberAnnotations = [Annotation01, Annotation02]
   @Stereotype {}

// stereotype fields are here


The developer of the custom type can annotate each field with Annotation01 and Annotation02, which are also Record types of type Annotation.

Each classifier supports zero to many stereotypes. For example, a Handler type can include a declaration of RUIHandler or RUIWidget. A developer who codes a custom type selects from the stereotype list that is specific to a classifier.

EGL Packages

An EGL package is a container of EGL types, each of which has a name that is unique to the package. For example, a program and a data item of the same name cannot be in the same package. In general terms, the package is a namespace, which is a container in which the immediately subordinate names are unique.

The package corresponds to a set of subfolders in a directory. The subfolders correspond to the package name.

Package names

A package name is a sequence of names with intervening periods (.). Here is an example:


Each name is that of a subfolder in a hierarchy. The hierarchy for the current example is expressed as follows on a Windows platform:


The EGL parts are in files in the bottommost subfolder; here, the myPkg subfolder.

You might invert the list of qualifiers in your company's Internet domain name and assign the resulting list to the start of your package names. For example, if the domain name is, you might start your package names with com.mydepartment.mydivision.mycompany. This convention is often used. A benefit is that your packages will be unique even if your company merges or collaborates with another.

Package names are case sensitive; myPkg is different from MYpkg.

Although a package corresponds to a set of subfolders, an EGL package is a collection of types. The subfolders and related files represent only how those types are stored.

Package statement

Each EGL source file in a named package must start with a statement that identifies the package. The statement provides a kind of documentation, as in the following example:

package myPkg;

Default package

An Eclipse project includes a default package, which is a package that has no name. Other packages cannot access the types that are defined in a default package.

When you use a default package, the directory that contains the package includes all the EGL source files that are in that package. In this case, a source file does not start with a package statement.

Package import 

The EGL import statement provides access to the types in a second, named package. The import statement is used in two ways:

  • A statement that explicitly provides access to a specific part in a package in called a one-type import statement. The type is always available at compilation time.

    Here is an example statement:
import myPkg.MyProgram;
  • A statement that provides access to a set of types in a package is called an on-demand import statement because the types that are actually required are made available only as needed.

    Here is an example statement:
import myPkg.*; 
The example makes available all the types in the myPkg package.

An import statement can give access to types that are in another package repository, which is a directory or compressed file that holds one or more packages. Access requires that you reference the package repository in the EGL build path, which is a list of repositories.

Type-name resolution

The rules for type-name resolution define the search order that the compiler follows to resolve a type reference; for example, in a variable declaration. The compiler considers the current package directory and the repositories in the EGL build path. The compiler stops the search only when the same-named type is found or, if no type is found, only after all locations are searched.

The rest of this description assumes that the compiler is seeking the myType type in the myPkg package. Also, change "current project" to "current directory" if the search occurs in the EGL SDK.

If the reference is fully qualified, as in the case of myPkg.myType, the compiler seeks the type in the current project and then in every repository in the EGL build path. The search through the repositories is in build-path order.

If the reference is not fully qualified, as in the case of myType, the compiler gives priority to packages in the following order:

  1. The package identified in a one-type import statement such as
    import myPkg.myType;

    The compiler seeks the type in the current project and then in every repository in the EGL build path, in build-path order.

  2. The current package.

    The compiler seeks the type in the current project and then in every repository in the EGL build path, in build-path order.

  3. The package identified in an on-demand import statement such as
    import myPkg.*;.

    The compiler seeks the type in the current project or directory and then in every repository in the EGL build path, in build-path order. The search ends as soon as a type is found. However, if multiple on-demand import statements reference the same type, the search results in an error.

Scoping rules

The scoping rules tell whether a given variable, constant, parameter, or function is visible to an expression.  

The order of priority for resolving a reference is as follows:

  1. First in precedence are declarations that are local to the function where the expression resides. This category includes variable, constant, and function-parameter declarations.
  2. Second in precedence are declarations that are outside of a function but are inside the type where the expression resides. Each field is program global, which means that it is accessible to all members in the type. This category includes variable, constant, program-parameter, and function declarations.
  3. Third are declarations that are outside a function but are inside a library that is accessible to the expression. Each public field is run-unit global, which means that it is accessible to all functions in the run unit. This category includes the variable, constant, and function declarations in the library. Those declarations are program global to other functions in the same library.

A reference in an expression can include a series of identifiers, with a period (.) separating one from the next. Here is an expression in which each operand is fully qualified:

autoPkg.AutoLibrary.numberInFleet –

As appropriate, the identifiers can include a package name, the name of a container type, the name of a contained type, and a field name. A contained type can itself be a container type, to any level of depth.

The package and type names are especially useful for accessing values and functions in a library, as suggested in the example. However, for library access you can code a use statement, which offers the convenience of referring more directly to the declarations inside the library.

If a local declaration has the same name as the program-global declaration, only the local declaration is visible to the expression; but you can override that rule by using the this keyword.

Back to the top