What about tree rewriting?

Karsten Wagner wrote:

Is it possible yet? Maybe create one or more intermediate languages and translate from the prim�ry language thru the intermediate languages to maybe an extended version of baseLanguage and then create Java-, C# or eben C++ code from this?

Of course there must be some rewrite language to make it easy (in the moment it will be only possible to in java I suspect). Have you thought about one yet?

I like the concept of txl (http://www.txl.ca/, but I suppose you know it) to use patterns to match whole trees or part of trees and replace them with some other tree. This gives rather 'distributed' rulesets with many small rules which could be easily reused later via inheritance.

In MPS it should be possible to maintain the intermediate trees and use it for instant inspection and debugging:

You can view and even edit the intermediate languages via MPS or use the information from an intermediate node to display informations if the cursor hovers over the corresponding node in the input language.

For this task you can use MPS generator framework. Queries with

templates looks like rewriter rules. After model query language will be

completed you can do it almost without writing any code in Java.

I see. Is it possible to view, edit and access the intermediate code? Would be nice for debugging the rules or add nice tooltips to the source code based on the intermediate language.

Karsten Wagner wrote:

I see. Is it possible to view, edit and access the intermediate code? Would be nice for debugging the rules or add nice tooltips to the source code based on the intermediate language.

We have no intermediate code yet. Everything is generated to java them

compiled in IDEA and loaded back to MPS.

Or you mean something else?

I know, that you don't have it now, but you wrote that its possible to use the generator framework to create something like an intermediate code which is then translated into another language etc.

With other words: Use multiple passes to chain multiple languages together instead of creating one single big language which directly transforms everything in one step (which is a useful and common pattern in writing compilers). Another thing is to chain multiple rulesets and use the same language everytime, but make different transformations while building some external data structures of augmenting the code with additional informations which is later used in code-generation.

Karsten Wagner wrote:

I know, that you don't have it now, but you wrote that its possible to use the generator framework to create something like an intermediate code which is then translated into another language etc.

With other words: Use multiple passes to chain multiple languages together instead of creating one single big language which directly transforms everything in one step (which is a useful and common pattern in writing compilers). Another thing is to chain multiple rulesets and use the same language everytime, but make different transformations while building some external data structures of augmenting the code with additional informations which is later used in code-generation.

We have such thing in MPS. Model query language that is currently under

development is translated to collection language that in turn translated

to baseLanguage that is serialized to text presentation and compiled in

IDEA.

Karsten Wagner wrote:

I know, that you don't have it now, but you wrote that its possible to use the generator framework to create something like an intermediate code which is then translated into another language etc.

With other words: Use multiple passes to chain multiple languages together instead of creating one single big language which directly transforms everything in one step (which is a useful and common pattern in writing compilers). Another thing is to chain multiple rulesets and use the same language everytime, but make different transformations while building some external data structures of augmenting the code with additional informations which is later used in code-generation.

It is possible to writer generator such a way that it is possible to

look at intermediate result. In generator properties you can choose you

custom generator class that can save intermediate models at apropriate

places. Of course some generator debuggin functionality will be

implemented with the advent of more complex generators than we have now.

Hi Karsten and Konstantin,

It seems that the thread above shows signs of misunderstanding :-)

We use tree rewriting, there are intermediate models and intermediate languages.

Transformation language has three kind of rules:

-mapping rules;

-weaving rules and;

-reduction rules – these are for tree rewriting.

What we don’t have is matching patterns. As you know we use queries written in java.

During generation we transform source model to intermediate mode1, then, if necessary, to intermediate model2 and so on until we have no more reduction rules to apply.

And then we output last model to text.

Karsten is right: intermediate model are very useful for template development and I often turn saving on when writing templates.

The first intermediate language will be CollectionsLanguage which extends BaseLanguage and which is extended by ModelQuerylanguage.

In process of generation, expressions (or subtrees) in ModelQueryLanguage are reduced (or rewritten) to expressions in CollectionLanguage which are in turn reduced to expression in BaseLanguage.            

Igor

I suppose 'weaving' means something like 'replace something anywhere' while 'mapping' means 'replace the whole tree'. Is that true?

Will the query language support pattern matching? Its a very powerful concept, even if its not very object oriented. When I used a functional/oo language (ocaml) I don't even had a need for OOP because pattern matching is often more powerful.

And is (or will) the intermediate tree be accessible (for vieing/editing) later? I think that would be important for debugging, because you can allways look in the 'middle' of your working system without creating test scenarios.

I suppose 'weaving' means something like 'replace

something anywhere' while 'mapping' means 'replace

the whole tree'. Is that true?

In my view term 'replace' is not exact here because mapping+weaving can produce tree with completely different topology. Source roots often result in one or more leafs, and source leaf can result in target root.

Mapping rule transforms source node to root node in target model and creates context for weaving.

Weaving rule inserts subtrees into context created on 1st step.

igor.

Will the query language support pattern matching? Its

a very powerful concept, even if its not very object

oriented. When I used a functional/oo language

(ocaml) I don't even had a need for OOP because

pattern matching is often more powerful.

And is (or will) the intermediate tree be accessible

(for vieing/editing) later? I think that would be

important for debugging, because you can allways look

in the 'middle' of your working system without

creating test scenarios.

Agree, these both features would be extremely useful. Unfortunately we hardly can implement them in nearest future.