Extending generator plan?

Some language aspects use a generator plan (typesystem, for instance).  For that reason, I don't see any way to use a new language in the typesystem aspect. The new language's generator just doesn't engage at all.  What do I have to do to make this work?

4 comments

What sort of a language you'd like to have in your typesystem aspect? E.g. if it is an extension to one of languages included into the plan, it might be accomplished with a statement in the plan that tells to include extending languages/generators as well. For example, typesystem plan uses 'apply with extended' statement that would include generators that extend one from lang.typesystem. Perhaps, there are other scenarios the plan shall accommodate, then we shall fix it to mark other generators as 'with extended'. Otherwise, if your scenario is more complicated, you can use your own devkit with whatever GP you find suitable.

FWIW, it's sort of intentional to keep plans "confined", to give more sense to language aspect models and to force better structure overall. I.e. it's odd to see baselanguage classes mixed with a structure definition or some plugn extension points in typesystem. Therefore, we'd like to keep GPs tailored to scenarios of each aspect, with a flip side of less freedom when placing arbitrary nodes into aspect models.

1

Thanks for the reply.

In this case in particular, my language is a small extension to the smodel language.  I've added an SNodeOperation to do a simple task. FWIW, I solved my issue with a "hack" of extending the typesystem generator. Definitely not ideal though.

 

It surprises me that the "transform" in the genplan doesn't include extended languages, and you have to specify a generator specifically.  This could perhaps be better documented.  It also would be *very* useful to have an error message if I add a language that won't be generated because of a genplan.  I spent a lot of time trying to understand why my nodes weren't being reduced properly ;-)

 

I see why you'd want to keep the various aspects separate. That does make a lot of sense.  Though all of the aspects languages use baseLanguage anyway, so it would be possible to add classes anywhere.  Perhaps a different approach would be helpful.  For example, an "ModelConstraints" concept, which could veto root nodes. That could be part of defining an aspect.  It would allow a lot more flexibility of importing different languages, while keeping aspect models "clean".

 

0

"Show generatoion plan" action tells if there's custom GP for a model, and lists exact generators that would get included, so that one can notice a language is missing. Indeed, MPS could go an extra mile and notice language uses in the model without generator in GP and report them to draw attention to. You might want to file an issue to have this feature implemented.

lang.smodel is definitely worth to get listed 'with extensions' in the plan, just need to make sure it doesn't unexpectedly break anything else out there.

0

Thanks for the response.  I have opened MPS-29720 as a feature request to add a warning. 

0

Please sign in to leave a comment.