Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » compilation phases
compilation phases [message #23997] Thu, 17 May 2007 19:24 Go to next message
Miguel Garcia is currently offline Miguel GarciaFriend
Messages: 77
Registered: July 2009
Member
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 20:01 Go to previous messageGo to next message
Eclipse UserFriend
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
reported as https://bugs.eclipse.org/bugs/show_bug.cgi?id=187679 [message #24063 is a reply to message #24032] Thu, 17 May 2007 20:40 Go to previous message
Miguel Garcia is currently offline Miguel GarciaFriend
Messages: 77
Registered: July 2009
Member
Miguel
Previous Topic:validate constraints added to profile
Next Topic:OCL console
Goto Forum:
  


Current Time: Mon Nov 24 16:22:23 GMT 2014

Powered by FUDForum. Page generated in 0.01846 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software