Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [viatra-dev] Transformation API

Hi,

just some clarifications here; I will update the wiki page later.

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.

3) Portability: there are three main concepts (rules, statements and model manipulation primitives), that are modeled and implemented orthogonally: each of them can be used or left out as required. This means, if we want to support a different modeling paradigm, we would need another model manipulation implementation (that does not even have to have the same API); all other concepts are re-usable.

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.

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.

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

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



Back to the top