Transformations in Paml

Transformations concept is not a new one; they are already defined and used in MDD. But the idea of Paml is to make transformations simpler and available for developers as a language feature for daily working.

Transformations in Paml extend and generalize aspect concepts from AOP. We could consider much more of functionality as aspects, which could be separated from domain models to keep them (the domain models) as simple, abstract and pure as possible. The application complexity will be added exactly by transformations to "pure" domain models.

If keep developing the idea of transformations as aspects, it seems that transformations could even define semantics of domain models, while the domain models just specify syntax/notation/terms in almost free manner but in some fixed language paradigm of course. But this is only an assumption.

Transformations are a way of functionality reusing. It is not based on belonging models to some base term like class inheritance, but composing functionality in the way that a transformation can be applied to multiple appropriate model elements to they share some functionality from the transformation.

Separation source code and functionality into models and transformations defines fixed order in development, but this order and related restrictions look like helping to avoid development problems that are usually solved by patterns, idioms and similar restrictive technics.

Transformations define also formal semantics of operations, which could be provided by IDE. Transformations are actually source code that operates other source code (domain object models), so IDE could do all such actions, so the domain models would be the only source code in such case.

Moreover, the nature of transformations is a manipulating domain models, so transformations is a way of metaprogramming to produce source code in GPL instead of writing it manually. Metaprogramming allows using alternative abstractions in modeling for writing programs.