[news.eclipse.modeling.mdt.uml2.ocl] Re: [OCL] Any plans on parser exten

["Christian W. Damus" <cdamus@xxxxxxxxxx>]

Hi, Radek,

Find some responses in-line, below.

Cheers,

Christian


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).

I haven't given any thought to providing extensibility of the grammar or
what QVT may need in that respect (hopefully the M2M folks have some
ideas).  For myself, I am sufficiently green in parser-generator technology
(in general, and LPG in particular) and constrained by my schedule that it
won't be feasible for me to tackle this problem in this release.  If some
supporter from the community can determine how to implement an extensible
grammar with LPG and contribute it, then hopefully I would be able to find
the time to review it.


> 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.

Again, I don't know enough about LPG even to say how feasible this is.  This
would be another good area for contribution ...


> 3) Debugging (Hooking into EvaluationVisitorImpl)
> There is a post in EMFT newsgroup
>
(http://dev.eclipse.org/newslists/news.eclipse.technology.emft/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 ;-))).

I see; you're looking to create something like a DebugEnvironment that wraps
the default visitor to observe the walking of the AST?  That sounds like it
can be accommodated by providing an EMF-style protected factory method in
the environment, that you can override.  The work in progress on
J2SE5.0/UML support has a single visitor implementation supporting
evaluation for all language bindings (Ecore, UML, ...), so it's just a
matter of allowing a client to wrap it (binding specifics are handled by
the EvaluationEnvironment).


> 
> 
> Regards,
> /Radek