Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Re: [OCL] Any plans on parser extensibility, error recovery ?
Re: [OCL] Any plans on parser extensibility, error recovery ? [message #9464] Wed, 28 February 2007 19:40 Go to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
[Continuing the thread from the now read-only eclipse.modeling.mdt.uml.ocl]

Hi Radek

You may find a slight adaption of the grammars to support extension
for QVT relation in
/cvsroot/technology/org.eclipse.gmt/umlx/plugins/org.eclipse .gmt.umlx.eqvtr.cst
The CVS is currently for OCL 1.1M4.

I have just upgraded to OCL 1.1M5 and am tidying up prior to submitting the
only slightly revised org.eclipse.ocl.internal.parser package in the hope
that with encouragement from us, Christian will find time to incorporate it.

The revision supports grammar extension to realise QVTrelation and introduction
of an ErrorHandler so that custom error handling policies can be supported.
I want my errors to go to IMarker instances so that my meta-model validating
QVTr editor does what you'd expect.

Regards

Ed Willink

Radek Dvorak wrote:
> Hi,
>
> I have few questions on topics that come into play when starting to build
> other tools based on MDT OCL.
>
> 1) OCLparser extensibility
> Other languages built as an extension to OCL (like QVT) could
> benefit from the existing OCL grammar and generated parser and
> provide only those constructs that forms the extension.
> I know that EMFT newsgroup mentions that its OCL parser was not designed
> with extensibility in mind and I am just asking whether this was not
> reconsidered
> with respect to the new M2M project (QVT component).
>
> 2) Error recovery
> Currently, only the fail-fast approach is implemented and there is no
> comprehensive diagnosing
> which accumulates errors encountered during the parsing phase and also by
> the well-formedness
> validation. Reporting these along with the error locations would help a lot
> in development
> of complex OCL expressions.
>
> 3) Debugging (Hooking into EvaluationVisitorImpl)
> There is a post in EMFT newsgroup
> ( http://dev.eclipse.org/newslists/news.eclipse.technology.emf t/msg01547.html)
> on the possibility
> to extend the evaluation visitor.
> The answer here is that "operation calls or property/association-class
> navigation"
> will be provided by the EvaluationEnvironment instead.
> My point is that it would be useful to have a finer-grained hook into the
> evaluation
> process, especially for OCL debugging support needs. In such a case,
> involving something
> like EvaluationVisitor interface seems to me a more suitable alternative to
> be used when implementing
> a DebugEvent aware OCL evaluation (unless debugging is gonna be specially
> handled in MDT OCL itself ;-))).
>
>
> Regards,
> /Radek
>
>
>
Re: [OCL] Any plans on parser extensibility, error recovery ? [message #9539 is a reply to message #9464] Thu, 01 March 2007 22:14 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
See Bugzilla 176110 for an extensible version of the OCL parser,
a QVTrelation extension of the parser and customisable error handling.
Re: [OCL] Any plans on parser extensibility, error recovery ? [message #9659 is a reply to message #9539] Tue, 06 March 2007 21:25 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Ed,

Thanks! I'll have a look at it.

Christian

Ed Willink wrote:

> See Bugzilla 176110 for an extensible version of the OCL parser,
> a QVTrelation extension of the parser and customisable error handling.
Previous Topic:allInstances
Next Topic:Traversing associations that own their ends in OCL
Goto Forum:
  


Current Time: Fri Mar 29 13:06:56 GMT 2024

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

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

Back to the top