Code generation & Co


#1

Hi,

in the last workshop in Leuven I mentioned a personal concern about the possible limitations of static code generation.

To be precise, the creation of C++ source code from a model and the fact that most of the time I just saw a one-way transformation.

My points is that executable models could be in some cases a preferable approach in some applications, being State Machines and Behavior Trees a practical example.

On the other hand, my “doubts” (concerns? misunderstanding? prejudice?) would go away if the programming environment allows me to have seamless two-ways transformations between models and source code.

Is anyone aware of any tooling / modelling language that supports two-ways transformations?

My gut-feeling is that model-to-code is relatively easy to implement, even from scratch, whilst code-to-model can be achieved using C++ parsing tools such as libclang.

Cheers


#2

Hi @facontidavide,

First of all, thanks for bringing up such an interesting topic! :slight_smile:

A small preamble, maybe a bit nitpicking, but just trying to be as much correct as I can: I think that static code generation has no intrinsic limitations. Or better, there are pro/cons with respect to dynamic code generation, but it would be more appropriate to talk about (usual) limitations of the tools behind static code generation.

Discussing about the pro/cons of static vs dynamic code generation (no tools!) is more about what you can do/not do, e.g., optimise or not optimise.
For example, there are some cases where static generation is the only way to go (real-time systems, usage resources, etc).

Then, there is another discussion (that I would keep separated) about the developer workflow: “scripting” (just to use a less formal term) usually works better, in practise, to keep the focus and get first proof-of-concepts. It is too easy in fact, to loose focus while waiting for some code to compile. This is more an human factor (an important one!), but not technical.

Finally, there is the discussion on the tools, which is what you are referring to.

Going back in topic, I personally buy your concern, and I also prefer/wish tools that allow two-ways transformations. I’ve also being looking for frameworks that allow this. But it is not that common, and the major technical challenges are two, AFAIK: (1) transformation from code to model after that the code has been modified, and (2) in case of a concurrent development, that is, a developer changes the model while another changes the code.

AFAIK yes, there is something around, but mostly limited in one direction or another. I had this discussion last year with @mmorelli , and he/CEA presented something that goes in that direction during the workshop. But it was about model-to-model, and not model-to-code, if I am not mistaking.
I am also aware of few tools that goes in this direction in Eclipse, but I have no direct experience with them. I can search for them again (I can’t recall by hand), but probably @mmorelli could give you few pointers in this direction.

In general, it won’t be easy (or even not possible?) to do so without imposing any constraint or limitations (which I believe is possible to do, since the tool should be targeted to a specific case).
Another approach would be to do so in a semi-automatic form, that is, after modifying the code the user must provide some sort of annotations, from which the tool can interpret the code and get the model back. In fact, the problem is that you loose semantic meaning if you impose changes directly into code, without model those changes (the annotation I am proposing are, in fact, a model).

Those are just my personal thoughts, and I am curious to hear about the others! :slight_smile:


#3

Thanks @enea.scioni for your feedback.

(1) transformation from code to model after that the code has been modified

I am 95% positive that nowadays libclang and clang tools are the best way to achieve code-to-model transformation, even without annotations, as long as the function/class API has a 1-to-1 mapping with the model.

I also guess that it would not be too challenging for someone already familiar with libclang… on the other hand, it would surely be hard for the rest of us mortals :wink:

I might play with this (for fun) the last month of the project :smiley:


#4

That is a very concrete and strong limitation, that (unfortunately) does not hold in many cases. (Nitpicking mode on: a mapping 1:1 is an annotation already, but one that does not show up directly into the tool implementation. Still, you have it. :stuck_out_tongue_closed_eyes:) There might be others, depending on the specific case. Another would be the target; LLVM-IR?
So, yes, if you restrict yourself to a tool that handle very specific cases, it would be definitely possible.

I am familiar with libclang (just enough to say that it is not libclang that you are looking for, but LLVM), but I won’t say I am an expert of it (not enough to state how much effort would be needed)… :stuck_out_tongue:

Keep us posted! Even for fun, and even after the project duration!
:smile:


#5

Enea: “I am familiar with libclang (just enough to say that it is not libclang that you are looking for, but LLVM)”

image