| compilation phases [message #23997] |
Thu, 17 May 2007 15:24  |
Eclipse User |
|
|
|
Hi,
I'm still parsing .ocl files, with a view towards compiling them into Java.
I've got a problem with forward references across class declarations.
Example follows:
Let's assume two classes, each with an association end targeting the other
(Emfatic notation):
class A {
ref B refToB;
}
class B {
ref A refToA;
}
And the following .ocl file, def'ining attributes in each class, with the
mandatory initialization (here's where the forward references show up):
package p
context A
def dA: sa : String = refToB.sb
context B
def dB: sb : String = refToA.sa
endpackage
I get the following error:
org.eclipse.ocl.SemanticException: ERROR in (variableExpCS): (Unrecognized
variable: (sb))
Taking as input the whole .ocl is a useful convenience operation. However, I
miss finer control over the ASTs that are being built: I haven't found the
API-supported-way to take apart two conceptually different phases: property
definition (what comes before the equals sign in a def statement) and then
initialization (what comes after).
The above is motivated in an OCL -> Java compilation scenario, where there
are several .ecore and several .ocl as input. The only way I see to get the
ASTs correctly built is:
a) process the "def section up to the equals sign" for all .ocl files,
(which can be done in any order as each refers only to types already in
scope)
b) process the rest:
b.1) initializations
b.1.1) "what comes after the equals in def statements"
b.1.2) init statements
b.2) body statements,
b.3) der statements
etc.
Help is welcome ...
Miguel
|
|
|
| Re: compilation phases [message #24032 is a reply to message #23997] |
Thu, 17 May 2007 16:01  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Miguel,
Yeah, this is one of those subtleties that the OCL specification didn't
consider, but probably rightly so, being out of scope of the language.
This is more of an implementation detail in the parser, not a grammar
issue.
You will not be able to twist the current parser API, not even using the
internals, I think, to implement this kind of two-stage parse.
It shouldn't be hard, though, to do this as an enhancement in the 1.2
release. We already have a separation of the concrete-syntax and
abstract-syntax parsing phases, so all that remains is to
* parse the concrete syntax of all def: expressions first, to
pre-define the signatures. Then, parse the CS of all other
constraints and the def: expression bodies to produce the ASTs
* enhance the parsing API to support multi-document inputs
Please, raise an enhancement request in Bugzilla; hopefully 1.2 planning
will start fairly soonish.
Cheers,
Christian
Miguel Garcia wrote:
>
> Hi,
>
> I'm still parsing .ocl files, with a view towards compiling them into
> Java. I've got a problem with forward references across class
> declarations. Example follows:
>
> Let's assume two classes, each with an association end targeting the other
> (Emfatic notation):
>
> class A {
> ref B refToB;
> }
>
> class B {
> ref A refToA;
> }
>
> And the following .ocl file, def'ining attributes in each class, with the
> mandatory initialization (here's where the forward references show up):
>
> package p
>
> context A
> def dA: sa : String = refToB.sb
>
> context B
> def dB: sb : String = refToA.sa
>
> endpackage
>
> I get the following error:
> org.eclipse.ocl.SemanticException: ERROR in (variableExpCS): (Unrecognized
> variable: (sb))
>
> Taking as input the whole .ocl is a useful convenience operation. However,
> I miss finer control over the ASTs that are being built: I haven't found
> the API-supported-way to take apart two conceptually different phases:
> property definition (what comes before the equals sign in a def statement)
> and then initialization (what comes after).
>
> The above is motivated in an OCL -> Java compilation scenario, where there
> are several .ecore and several .ocl as input. The only way I see to get
> the ASTs correctly built is:
>
> a) process the "def section up to the equals sign" for all .ocl files,
> (which can be done in any order as each refers only to types already in
> scope)
> b) process the rest:
> b.1) initializations
> b.1.1) "what comes after the equals in def statements"
> b.1.2) init statements
> b.2) body statements,
> b.3) der statements
> etc.
>
> Help is welcome ...
>
>
> Miguel
|
|
|
|
Powered by
FUDForum. Page generated in 0.03996 seconds
Home