Thanks Peter. Those are very good points. I'll simplify the grammar. FYI there was not a lot of rationale behind the grammar. The main reason for it is that it was derived from the intermediate meta-model, but we'll refine it to make it more usable.
I'll make most names optional, although they can be useful, since content-assist does not yet show qualified names, so giving explicit names can help differentiate them.
For redefinitions, the only thing the user would be required to do is at the class/capsule level, e.g.
capsule A
{
// ...
}
capsule B
{
redefines A
//...
}
Of course, a user can specify refinement relations inside a state machine, for example if some state S2 of B redefines some state S1 of A.
The question is what to do with elements that have the same name but there is no explicit redefinition relation, for example, should we interpret state S1 of B to redefine state S1 of A even when there is no explicit redefinition? Currently the code generator interprets such situations as redefinitions, so that the generated code for B will have a function corresponding to S1 of B and nothing for S1 of A (but the code for A will have the state function for its own S1).
I think explicit redefinitions should be necessary only in the case where the elements involved have different names, would you agree?
By the way, the (GUI) tooling does not yet do any automatic redefinitions. The code generator uses redefinitions if it finds them, but if not, it uses the strategy outlined above, treating elements with the same name as redefinitions.