Re: [viatra-dev] Transformation API

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi, all

On 2013.10.09., at 12:18, Istvan Rath <rath@xxxxxxxxxx> wrote:

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

It depends on what do you think about de-eclipse-ified. If you mean, no Eclipse dependency, then you are right. If you mean, no Eclipse IDE, then it seems possible, as Xtext/Xtend can be run in standalone mode (just we have to clean up our internal code which is planned right now).

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

Very good point. I should have reviewed better the EIQ matcher API; next week I will create a comparison table of the current status.

>> 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!
I think, we need not to have a primitive for selecting a rule from a rule group, as rule groups are entirely optional grouping. If you need, you may use them, but everything works without it.

But I agree that fireOne might need a better name.

> 
> 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?
Rule groups were added as an experiment to see whether they help, so a lot of required methods are missing (yet). There is nothing preventing adding extra methods with custom ConflictResolutions and adding the missing rule group methods except time.

Currently, rule groups work by selecting the default conflict resolver (that might be redefined if needed).


> 
> cheers
> Istvan
> 
> --
> Istvan RATH, PhD
> Research fellow
> Budapest University of Technology and Economics
> Fault Tolerant Systems Research Group
> 
> 
> 
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/viatra-dev


Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics