Markus proposes that we add some kind of naming of lists of identifiers so that it is not necessary to repeat the sameidentifier x != {a,b,c,d,e,f}; multiple times. While I can see the benefit of not duplicating code, I don;t really like the idea of adding lots of new constructions into the SmPL language. If one can make assignments to identifier lists, why not assignments to other things. And so on.
I suggest to introduce an interface for the general management of various lists for syntax elements.
Perhaps a solution would be to allow scripting code in metavariable declarations.
I imagine also that this would be a nice extra feature.
Then we could in principle get rid of all sorts of constraints.
I do not want to get rid of constraint specifications.
There would be no need to learn the SmPL constraints and where they could occur.
I find it usual that it takes some time to learn a new (programming) language.
One would just have to remember the syntax of one's preferred scripting language
I would prefer to see it in the direction that the domain-specific language "semantic patch language" is the primary target to find useful key words to which desired features will be mapped in an appropriate way.
Companion interfaces can also be offered for other language environments.
Similarly, one could get rid of the regular expression matching notation.
Why do you imagine such a feature deletion?
It would be too complicated to allow the code to have access to other metavariables being declared at the same time.
I am not so concerned about this aspect.
But if an appropriate syntax for declaring them could be found, it would be possible to allow metavariables to be inherited from previous rules.
I am very curious on the support for SmPL rule hierarchies which would enable reuse of common specifications.
Currently we have @@ to separate metavariable declarations from the script code. Perhaps we could use that, although it seems a bit ugly.
Would you like to make these delimiter characters configurable?
Another option would be to have no separator.
I find the SmPL code easier to read with the extra separation. Regards, Markus _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
