Higher order transformations

[RFR]

Hi,

The Tefkat transformation language is based on a metamodel. Is it
possible to translate a transformation into an instance of this
metamodel, apply a Tefkat transformation on this instance and
translate the result back to a textual transformation specification?

In other words: are higher order transformations feasible in some way?

Regards

René

[Jim Steel]

It's not a case of translating the transformation into an instance of
the metamodel - it always is an instance of the metamodel. I'm not
sure that I'd call that higher order, so much as reflective, but yes,
that's quite possible.

Jim

[RFR]

> It's not a case of translating the transformation into an instance of
> the metamodel - it always is an instance of the metamodel.

OK - logically of course - but not in a workable representation (XMI).
Better: how to translate it into a workable format?

René

On 20 Sep., 17:19, "Jim Steel" <jimst...@gmail.com> wrote:
> It's not a case of translating the transformation into an instance of
> the metamodel - it always is an instance of the metamodel. I'm not
> sure that I'd call that higher order, so much as reflective, but yes,
> that's quite possible.
>
> Jim
>

> On 9/21/07, RFR <rene.fre...@student.hpi.uni-potsdam.de> wrote:
>
>
>
>
>
> > Hi,
>
> > The Tefkat transformation language is based on a metamodel. Is it
> > possible to translate a transformation into an instance of this
> > metamodel, apply a Tefkat transformation on this instance and
> > translate the result back to a textual transformation specification?
>
> > In other words: are higher order transformations feasible in some way?
>
> > Regards
>

> > René- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Kerry Raymond]

> OK - logically of course - but not in a workable representation (XMI).
> Better: how to translate it into a workable format?

I'm not sure I understand the question.

A transformation is an instance of a model like any other source/target. So
it can be manipulated like anything else. I don't have the model handy (so I
am making this up a bit) but you could write rules like ...

RULE doSomethingForEachRule
FORALL TRULE tr
WHERE
tr.expr.term = T,
blah blah blah

It is also possible to use the trace file created by an execution of the
Tefkat engine as a source to a transformation, so you can analyse
relationships between some source and target files. However, while it's
possible, it's a bit messy to do. It would be nice to have some extra
concrete syntax that could be used when working with source/targets that are
known to be Tefkat transformations or Tefkat trace files. Note that adding
extra concrete syntax doesn't imply changing the underlying Tefkat model; it
just means there are easy ways to express something that translates under
the hood into something messy. That would make "meta-transformations" easier
to write.

Kerry

[RFR]

Hi

> A transformation is an instance of a model like any other source/target.

I know that from the theoretical point of view such a transformation
of transformations is no problem, since a transformation is completely
described by the Tefkat-metamodel.

What I want to know is how to get a transformable XMI-file from
the .qvt source file. ATL has injectors for that task. They support
translation from an ATL-file to an Ecore-representation. After the
transformation the resulting Ecore-file can be translated back to ATL
source code. Is there a similar mechanism available for Tefkat?

Regards
René

[michael lawley]

Hi Rene

There is a ResourceFactory that will parse a .qvt (Tefkat concrete
syntax) and produce the corresponding Resource containing the model
you want. Tefkat automatically registers this factory for the
extension .qvt so you can just specify the .qvt file as a source
model.

Unfortunately, there is a semantic gap between the concrete syntax and
the model so a printer (to write out a .qvt file) is not so easy. I
have part of one written using XSLT that takes an XMI file as input
and I believe there is another one by David Hearnden that operates
directly on the model but I don't know how complete it is. Of course,
a printer is only needed if you want to be able to read the result --
the Tefkat engine can always load and execute a transformation from
its XMI representation.

michael

[David]

Hi Rene,

As Michael said, if Tefkat loads a resource foo.qvt, then it is
transparently parsed into a transformation model. So you can
certainly write meta-transformations based on the classes in the
Tefkat metamodel, and just run the transformation on any
(textual) .qvt file. However, the result of that meta-transformation
will by default be serialised as XMI. If you want the output to
appear as textual .qvt (i.e., if you want to look at it at all!), then
you need a model-to-text printer.

I have written a printer for this, and there are some slightly non-
trivial aspects to the text transformation (combining MOFInstance
terms with their Injections, handling nameless variables, appropriate
generation of target keywords, etc). In my branch of Tefkat I use
some concrete syntax extensions (because there are some `valid' Tefkat
terms that don't have textual representations), so that may cause some
issues (there's one in particular that may need addressing). If you
think this printer would be useful for you, let me know and I'll
figure out a way to get a copy to you (I'll probably put it in my
Tefkat branch).

Cheers,

-David

On 21 Sep, 19:57, "michael lawley" <mich...@lawley.id.au> wrote:
> Hi Rene
>
> There is a ResourceFactory that will parse a .qvt (Tefkat concrete
> syntax) and produce the corresponding Resource containing the model
> you want. Tefkat automatically registers this factory for the
> extension .qvt so you can just specify the .qvt file as a source
> model.
>
> Unfortunately, there is a semantic gap between the concrete syntax and
> the model so a printer (to write out a .qvt file) is not so easy. I
> have part of one written using XSLT that takes an XMI file as input
> and I believe there is another one by David Hearnden that operates
> directly on the model but I don't know how complete it is. Of course,
> a printer is only needed if you want to be able to read the result --
> the Tefkat engine can always load and execute a transformation from
> its XMI representation.
>
> michael
>

> On 21/09/2007, RFR <rene.fre...@student.hpi.uni-potsdam.de> wrote:
>
>
>
> > Hi
>
> > > A transformation is an instance of a model like any other source/target.
>
> > I know that from the theoretical point of view such a transformation
> > of transformations is no problem, since a transformation is completely
> > described by the Tefkat-metamodel.
>
> > What I want to know is how to get a transformable XMI-file from
> > the .qvt source file. ATL has injectors for that task. They support
> > translation from an ATL-file to an Ecore-representation. After the
> > transformation the resulting Ecore-file can be translated back to ATL
> > source code. Is there a similar mechanism available for Tefkat?
>
> > Regards

> > Ren?

[RFR]

Hi David,

As I am using transformatons on transformation in order to provide
some kind of aspect orientated transformation definition approach, the
result is only used to put it in the engine. It does not have to be
editable and even not readable, too (it still is of course).

But thank you for your offers, anyway.

Regards
René

> > > > Kerry- Zitierten Text ausblenden -

[Kerry Raymond]

> It does not have to be editable and even not readable, too (it still is of
> course).

It may still be worthwhile to have a way to turn it back into Tefkat syntax
(or some close approximation) as it may make it a lot easier for you to
debug if you can see the transformations you are generating.

Transformations that generate transformations are unlikely to be simple and
my guess is you won't get them right the first time :-)

Kerry