On Fri, 18 Nov 2016, SF Markus Elfring wrote:
> >> https://github.com/coccinelle/coccinelle/blob/cbc751b30d9e02390d60ebed643c8e4a3fa0bb2b/tests/idcon_python.cocci#L1
> >
> > The syntax is curly brackets around a C expression.
>
> I do not understand this information completely at the moment.
>
>
> >>> Concretely, the script constraint code is initially parsed using a C
> >>> parser,
> >>
> >> I find such an information interesting to some degree.
> >>
> >> Why do you pass data to a software component for āCā at this place?
> >
> > Seemed convenient.
>
> I can not follow your views for software convenience with this detail so far.
>
>
> > Perhaps it could be possible to parse to a closing },
>
> I have got another idea in the meantime.
>
> I propose to distinguish these delimiters better for different use cases.
>
>
> > but your goal seems to be to put more complex terms in the script code
> > that might then include }, making things more complicated.
>
> I hope that it will be possible to pass growing programming scripts there.
>
>
> >> Have you got more control about the construction of a single function call?
> >
> > No.
>
> I find this answer strange.
>
>
> How do you think about to support cases like named and unnamed (ad hoc)
> predicates there?
>
> Examples:
>
>
> @ad_hoc_replacement@
> identifier ID: script:python() { return ID in ['a', 'c'] };
> @@
> -ID
> +36
>
>
> @initialize:python@
> @@
> def is_watched(id):
> return id in ['a', 'c']
>
> @structured_replacement@
> identifier ID: script:python() ā is_watched;
> @@
> -ID
> +18
No interest in supporting either. How are these so vastly better than:
@initialize:python@
@@
def is_watched(id):
return id in ['a', 'c']
@structured_replacement@
identifier ID: script:python() { is_watched(ID) };
@@
-ID
+18
julia_______________________________________________
Cocci mailing list
[email protected]
https://systeme.lip6.fr/mailman/listinfo/cocci
