Re: [viatra-dev] Transformation API

["Daniel Varro" <varro@xxxxxxxxxx>]

Hi Everyone,

> 
> 1) Goal and audience: what we have now is more of an API and not a
> dedicated transformation language. More specifically, there are some
> elements that are hard to use this way, because of the syntactic 
> limitations of Java/Xtend as a host language. On the other hand, one
> design goal was to provide an API that will be easy to use in the
> transformation language, so it should rely on entirely the same 
> concepts as the future language.
> 
> Alltogether, in the future, this API should be strictly an advanced-
> level concept, but for now, it is the only way to specify transformations.
> 
> 2) Re-use of technologies: the API relies on concepts of the Xtend
> language, as its concepts will be easy to integrate into a future
> domain-specific language.
> 
> However, the API is clearly usable in a plain Java API, but using
> Xtend reduces the level of boilerplate code required considerable,
> so until we have a dedicated language, I would strongly argue to use
> Xtend as an implementation language.
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.
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).

> 4) Naming conventions: this is the most important
part that needs to
> be cleaned up, as it is really important, and there is no single 
> good solution. I guess, this is the part where the most input is needed.

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.

> About the removal of the 'current' element, it is a very important
> distinction, so I am not sure whether the suggested solutions would
> be the best way. In this, I agree with Gábor, but I would like the
> opinion of István or Ákos, as they have more experience in this matter.
> 

My personal opinion for the current naming:
* getOneArbitraryMatch vs. fireOne: here the IQ version
is more descriptive, but maybe, too descriptive :).
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! 

* getAllMatches / forEachMatch vs fireAllCurrent:
For me, "current" is misleading as you cannot fire matches in
the past.
Iterating over all matches is the default behavior
in IQ, therefore the developer would expect the same
from an API function called "fireAllMatches"
or "fireEachMatch"..

* "fireWhilePossible": the correct use of
English is "as long as possible". It is especially
misleading, since we have "fireUntil" with
an explicit break condition - which is not
available for "fireWhile". So we might introduce
all "fireWhile", "fireUntil", 
"fireAsLongAsPossible" instead to be consistent.

Anyhow, this is only one opinion which might be considered.

Cheers,
Daniel

> On 2013.10.08., at 14:54, "Daniel Varro"
<varro@xxxxxxxxxx> wrote:
> 
> > Hi,
> > 
> > We need to work on setting up the scene for the Transformation
API in a 
> > better way.
> > 
> > 1) The wiki page should very precisely state the intended goal
and 
> > audience of the API. 
> > Is it intended to be used by tool developers or a more broader
audience?
> > Do we propose a language or "only" an API? If the latter,
will there be a 
> > language 
> > a transformation language as well at a later stage? 
> > 
> > (E.g.: Query specifications captured in the IQ language can be
showed to 
> > non-programmers,
> > while the examples using the Transformation API are restricted
to 
> > experienced programmers)
> > 
> > 2) To what an extent do we plan to reuse existing Eclipse technologies
> > (e.g. Xtend) ?
> > Is it intended as an execution framework, or also as a primary
> > transformation language?
> > 
> > 3) What kind of portability is planned for the Transformation
API / 
> > Language?
> > (The language of IQ is portable to graph models other than EMF
with minor 
> > adaptations)
> > 
> > 4) Naming conventions need to be revised. 
> > The "fireWhilePossible" should be renamed to "fireAsLongAsPossible"
which 
> > is a known terminology at least in the academic community
> > The "fireAllCurrent" and "fireOne" should
be renamed to in accordance with 
> > IQ termionology, so how about "fireForEachMatch" and
> > "fireOneArbitraryMatch"?
> > 
> > Cheers,
> > Daniel
> > 
> > 
> > 
> > 
> > From:   Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>
> > To:     Viatra developer discussions project <viatra-dev@xxxxxxxxxxx>
> > Date:   2013.09.20 17:06
> > Subject:        [viatra-dev] Transformation
API
> > Sent by:        viatra-dev-bounces@xxxxxxxxxxx
> > 
> > 
> > 
> > Hi,
> > 
> > as promised, I have set up a wiki page that describes the current
> > transformation API implementation: 
> > http://wiki.eclipse.org/VIATRA2/EMF/Transformation_API
> > 
> > The implementation is in an early stage, everything is open to
discussion; 
> > the page contains links to both the transformation API implementation
and 
> > the TTC2013 example code.
> > 
> > Cheers,
> > Zoltán
> > -- Zoltán Ujhelyi
> > https://www.inf.mit.bme.hu/en/members/ujhelyiz
> > 
> > Fault Tolerant Systems Research Group
> > Budapest University of Technology and Economics
> > 
> > _______________________________________________
> > viatra-dev mailing list
> > viatra-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/viatra-dev
> > 
> > _______________________________________________
> > viatra-dev mailing list
> > viatra-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/viatra-dev
> 
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/viatra-dev