Home » Modeling » M2T (model-to-text transformation) » A growable M2T language
A growable M2T language [message #1099] |
Mon, 06 November 2006 16:35 |
Eclipse User |
|
|
|
Originally posted by: gkevorki.sybase.com
Hello everyone,
Sybase is interested in participating in the project and discussions around
it.
We have had proprietary M2T technology (GTL) built into our PowerDesigner
modeling product for some time now (five years or so) and we are interested
in standardization efforts in that domain.
Given the profusion of template languages on the market, each one with its
own strengths and weaknesses, we believe that coming up with a standard
would be great, provided the latter offers room for extensibility.
I have to confess we haven't taken a close look at MOF2Text yet and what it
may offer in that respect, if it will turn out to be yet another "closed"
template language with hard-wired syntax and features or it will be open :).
We feel defining a bare-bones "growable" language
(http://portal.acm.org/citation.cfm?id=1176617.1176621) which would address
the domain of M2T and have built-in support for what is common to most M2T
languages could be a desirable goal within the context of this proposal.
Such a language would basically serve as a platform for building/integrating
new/existing languages and tooling built around this platform could benefit
all of them.
Built-in features might include, among other things:
- support for templates as meta-class extensions (templates are basically
methods returning strings)
- template polymorphism (which follows from the previous point)
- implicit this
- a syntax for "variable" substitution with support for object scopes
- a syntax for specifying macros/directives (IF, FOREACH...)
- template metaprogramming (evaluating the result of a template evaluation
as a template)
....
Macros would be provided through "libraries" thus their set would be
extensible.
Anyway, just a few initial thoughts.
Looking forward to participate in good discussions around M2T.
Best regards,
Gabriel Kevorkian
Senior Software Engineer
PowerDesigner R&D
Sybase, Inc.
|
|
| |
Re: A growable M2T language [message #1208 is a reply to message #1181] |
Wed, 08 November 2006 19:12 |
Eclipse User |
|
|
|
Originally posted by: gkevorki.sybase.com
Hi Markus,
They're all in PowerDesigner GTL too (since 2002 ;) ) (and in Acceleo, I
believe) and potentially other languages so they represent a reasonable
common denominator.
The level of abstraction should be raised a bit higher than suggested by the
points I listed for the language to be truly growable. As for the last point
("template metaprogramming"), it should not appear in the list, such support
could be provided by a "library" as an "operator".
Gabriel
__________________
Gabriel Kevorkian
Senior Software Engineer
PowerDesigner R&D
Sybase, Inc.
"Markus Voelter" <schogglad@web.de> wrote in message
news:op.tipijoh3474qjy@markust43...
> Hi,
>
>> - support for templates as meta-class extensions (templates are basically
>> methods returning strings)
>> - template polymorphism (which follows from the previous point)
>> - implicit this
>> - a syntax for "variable" substitution with support for object scopes
>> - a syntax for specifying macros/directives (IF, FOREACH...)
>> - template metaprogramming (evaluating the result of a template
>> evaluation as a template)
>
> Just FYI: all of these features except for the last one are
> actually already in oAW XPand.
>
> Markus
>
>
> --
> Markus V
|
|
| |
Re: A growable M2T language [message #2157 is a reply to message #1286] |
Tue, 14 November 2006 11:04 |
Eclipse User |
|
|
|
Originally posted by: gkevorki.sybase.com
Hi,
> oAW is already part of the M2T project.
I hadn't noticed ;-)
> we also want to pragmatically get results
I don't. LOL.
> How would such a growable language be different from what
exists today?
Ok seriously, I'll try to reformulate my initial post.
My point is that if you want to build a real M2T infrastructure, you need to
go beyond engine invocation and have knowledge of the language itself (its
semantics). Obviously, there are a number of existing languages. If you want
to preserve the diversity of languages while at the same time being able to
address them in a uniform manner, you need to define an abstract or
"growable" language these languages can "derive" from.
what exists today (correct me if I am wrong):
- not easily extensible proprietary languages (xPand, JET, Acceleo, GTL...)
eg I believe it is difficult to extend xPand's FOREACH directive or define a
"FOREACH2" without modifying the engine's source. In other words, even if
possible, extensions cannot be packaged/distributed easily (Note: in this
respect, it seems JET offers the ability to define custom tags)
- proprietary editors with different levels of capabilities (syntax
coloring, content assist when writing template logic...)
- a variety of implementations for supporting features (workflow,
integration with source code control, debuggability, traceability,
synchronization...)
what would be desirable in the context of an eclipse project:
- take a close look at existing m2t solutions so as to extract what is
common between them and build a platform around that core.
- define extension points to the core so as to ensure existing m2t solutions
can be adapted to the core and still provide the same level of
functionality. If well-designed such extension points could be used by
end-users themselves.
- taking advantage of the core, provide an implementation of an extensible
"universal" editor that could offer services that are not specific to any
given language (for instance, syntax coloring of the generated code, content
assist in the target language eg. if you are writing a template generating
Java code, it would nice to have some of the features of the Java editor
when writing the textual bits of generated code... I don't know if you have
done much meta-programming but having to cut & paste bits of code from a
template editor to a language editor just to get some intellisense can be
frustrating at times)
- build some supporting features around the core so that everyone can take
advantage of them (this is already included in part in the proposal although
things like debuggability or interop seem quite difficult to offer if some
common semantics are not defined)
examples about the need for abstraction:
- at the concrete syntax level
if you consider using guillemets is a leap for mankind compared to using %%,
$(), ${} or <%=%>... and you are not willing to lose such a big
differentiator for xPand ;-) , one would have to come up with some notion of
"variable block delimiter".
- at the abstract syntax level,
|
|
| |
Re: A growable M2T language [message #2492 is a reply to message #2157] |
Sun, 10 December 2006 12:07 |
Markus Voelter Messages: 33 Registered: July 2009 |
Member |
|
|
Sorry for not answering for such a long time. It still hasn't become
"daily routine" for me to look into the news groups...
> - not easily extensible proprietary languages (xPand, JET, Acceleo, =
> GTL...) eg I believe it is difficult to extend xPand's FOREACH =
> directive or define a "FOREACH2" without modifying the engine's source=
..
right. You cannot extend the language in that way.
(Btw, that would be *really* tough if you also want
to extend the editor...)
> In other words, even if
> possible, extensions cannot be packaged/distributed easily (Note: in t=
his
> respect, it seems JET offers the ability to define custom tags)
yes, and no. I mean, you can in xPand of course define
"library templates" than can do all kinds of stuff.
You can't really extend the language. AFAIK, that's the
same in JET.
> - take a close look at existing m2t solutions so as to extract what is=
> common between them and build a platform around that core.
> - define extension points to the core so as to ensure existing m2t =
> solutions
> can be adapted to the core and still provide the same level of
> functionality. If well-designed such extension points could be used by=
> end-users themselves.
yes. It's just that it's far from trivial to build
an extendible language - I haven't seen this in "normal"
programming languages yet.
> - at the concrete syntax level
> if you consider using guillemets is a leap for mankind compared to usi=
ng =
> %%, or <%=3D%>... and you are not willing to lose such a big
> differentiator for xPand ;-) , one would have to come up with some =
> notion of "variable block delimiter".
right. This particular feature is of course trivial.
> PS : All this may sound a bit ambitious
yes! I really think that is the core issue. As far as I
can see it, we simply don't have the resources to do something
like that, although I agree, it would be benefitial.
Markus
-- =
Markus V=F6lter
voelter - ingenieurb=FCro f=FCr softwaretechnologie
Ziegel=E4cker 11, 89520 Heidenheim, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@acm.org
Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net
PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
| |
Goto Forum:
Current Time: Thu Dec 26 12:15:24 GMT 2024
Powered by FUDForum. Page generated in 0.03875 seconds
|