Re: [viatra-dev] Transformation API

[Istvan Rath <rath@xxxxxxxxxx>]

Hi all,

On Wednesday, October 9, 2013 at 11:49 AM, Daniel Varro wrote: 

Yes, this is clear. We provide a way for Java / Xtend experts to write
transformations on top of IQ. We also agreed upon the alignment with Xtend.

IMHO, we need to be a bit more precise on this. The transformations are built on top of the EVM, which is in turn (partially) built on top of IQ. Using our API, you can write transformations with or without IQ (see e.g. the CEP project), but not without the EVM. This again raises the question of where (in which project, IQ or VIATRA) the EVM really belongs...

One more clarification with regard to Xtend: in my view, we are not just using Xtend as a host language, but also as a compile+runtime architecture in the sense that we (plan to) support both static-compile-to-Java and interpretative execution (+debugging). This affects the question of portability as VIATRA3 can thus be relatively easily "de-emf-ified" but not easily "de-eclipse-ified".

My main point is to warn VIATRA3 users that they do not get a
standalone transformation language with a precise formal semantics
(which was a selling point of VIATRA2 at least in academia).

Currently yes, but the "precise formal semantics" part can be added later on (with the assumption that we will restrict things for the transformation DSL). In our current vision, this is referred to as the "strict" variant of the language, whereas the unrestricted (and thus unanalyzable) one is the "relaxed".

 

Since EMF-IncQuery is being more and more an established technology,
any naming convention in VIATRA3 which deviates from IQ API will definitely cause
headaches for developers.

Maybe, we were wrong when selecting names for the IQ API , but consistency is
more important in my view. We need to avoid ad hoc decisions. 

I entirely agree. We should be coherent with whatever the current version of the IQ API is. But, as IQ has only had one release so far, and we are already up a version number from that, I think we still can change things on the IQ API as well, if necessary.

  

The down side of "fireOne" is that it can be misinterpreted when you have rule groups:
you can select one rule in a rule group and one match for a rule.
These two cases need API functions with different names!

Very good point!

By the way: is there a comfortable way of specifying how rule groups work?

The current example contains something like this:

//Trace information in preconditions express precedence - EVM can manage the concrete ordering
group.fireWhilePossible

 

What alternatives do I have if I don't want to use (only) trace information for precedence, conflict resolution etc?

cheers

Istvan

--

Istvan RATH, PhD

Research fellow
Budapest University of Technology and Economics

Fault Tolerant Systems Research Group