Jump to: navigation, search

Difference between revisions of "EDT:Extensible Compiler Development"

Line 33: Line 33:
 
To make the EGL code more consitant and readable, EDT will require all references to annotations to be preceded by a @. Previously, for annotations with a single value, we allowed the annotation to be specified without using the @. For example, consider the following annotation:<br>
 
To make the EGL code more consitant and readable, EDT will require all references to annotations to be preceded by a @. Previously, for annotations with a single value, we allowed the annotation to be specified without using the @. For example, consider the following annotation:<br>
  
Record stuff&nbsp;type Annotation {targets = [fieldMember]}
+
Record stuff&nbsp;type Annotation {targets = [fieldMember]}  
  
&nbsp;&nbsp;&nbsp; value boolean = false;
+
&nbsp;&nbsp;&nbsp; value boolean = false;  
  
end
+
end  
  
 +
<br>
  
 +
In RBD we allowed the following for this annotation:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; myfield record1 {stuff = true}
  
In RBD we allowed the following for this annotation:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; myfield record1 {stuff = true}
+
However, this is confusing, since there is no indication if "stuff" is an annotation or a field in the record Record1.  
 
+
However, this is confusing, since there is no indication if "stuff" is an annotation or a field in the record Record1.
+
  
 
To alleviate this, EDT will require that the user explicitly indicate all annotations. Therfore, the user will need to code the following to specify the annotation:&nbsp;  
 
To alleviate this, EDT will require that the user explicitly indicate all annotations. Therfore, the user will need to code the following to specify the annotation:&nbsp;  
  
&nbsp;&nbsp;&nbsp; myfield record1 [mailto:{@stuff{value {@stuff{value] = true}};
+
&nbsp;&nbsp;&nbsp; myfield record1 [mailto:{@stuff{value {@stuff{value] = true}};  
 +
 
 +
or
 +
 
 +
&nbsp;&nbsp; myField record1 [mailto:{@stuff{true {@stuff{true]}};
 +
 
 +
== Compiler updates<br> ==
  
or
+
TBD<br>
  
&nbsp;&nbsp; myField record1 [mailto:{@stuff{true {@stuff{true]}};
+
<br>
  
 
== Validation Design<br> ==
 
== Validation Design<br> ==

Revision as of 10:53, 16 July 2012

This page covers the work being done to make the compiler more extensible. Validation, for example, will be made extensible. A new model will be created so that bound AST will use IRs instead of bindings. The old binding model will still exist so that tooling written against it does not need to be rewritten. New tooling will be encouraged to use the new IR-based model.


Where to get the code

CVS repository: :extssh:<user>@dev.eclipse.org:/cvsroot/tools

Projects:
org.eclipse.edt.compiler
org.eclipse.edt.mof
org.eclipse.edt.mof.egl

Branch:
edtExtensibleCore


How to run the code

Right now you can only compile in SDK mode (the IDE builder will NOT work). Take a look at the "EGL2IR XML" Java Application launch configuration that's predefined. This will prompt you a couple times if you run it, or you can create a copy of this launch configuration and hard-code some values if you don't want to be prompted. Here's an example of hardcoded arguments:

-eglpath "/home/justin/.workspaces/edt-ext/test/EGLSource/" -irDestination "/home/justin/.workspaces/edt-ext/test/batchbin" -xmlOut "/home/justin/.workspaces/edt-ext/test/EGLSource/pkg/prog.egl"


Parser Updates

Several changes to the parser/lexer grammer files will be made:

  1. Remove primitive types
  2. Add ability for name types to include parameters. This is to support parameterizable types like eDecimal(5,2). This will requie the new expression to change, since the arguments to constructors will now be on the type.
  3. Refactor the isNullable flag to be on fields, function returns and array elements, instead of being on the type.
  4. Remove old keywords, such as FIELD and SQLNULLABLE from function parms


Annotation changes

To make the EGL code more consitant and readable, EDT will require all references to annotations to be preceded by a @. Previously, for annotations with a single value, we allowed the annotation to be specified without using the @. For example, consider the following annotation:

Record stuff type Annotation {targets = [fieldMember]}

    value boolean = false;

end


In RBD we allowed the following for this annotation:       myfield record1 {stuff = true}

However, this is confusing, since there is no indication if "stuff" is an annotation or a field in the record Record1.

To alleviate this, EDT will require that the user explicitly indicate all annotations. Therfore, the user will need to code the following to specify the annotation: 

    myfield record1 {@stuff{value = true}};

or

   myField record1 {@stuff{true}};

Compiler updates

TBD


Validation Design

TBD


Serialization Design

TBD