Front page | perl.perl5.porters |
Postings from May 2016
demerphq wrote:
>My second reaction to this is that without a quantifier or alternation
>(?:) is semantically invisible, and should that make a difference?
It should indeed be semantically invisible, but it is *syntactically*
visible, and yes, that does and must make a difference. /(?:ab)*/
is not the same thing as /ab*/.
>So I would expect /^*/ and /(?:^)*/ to produce the same compiled
>optree, and the same errors.
If they're syntactically legal (as they currently are), they should
indeed produce the same optree, and they currently do. However, it's not
essential for them to have the same syntactic legality. Hypothetically,
if we were to forbid applying a quantifier directly to /^/, we'd be
giving /^/ the same syntactic status as an already-quantified term,
such as /a{3}/. It's not legal to apply another quantifier to /a{3}/;
/a{3}{4}/ will generate a "nested quantifiers" error, and /^{4}/ could
similarly give an error. But it's perfectly legal to *semantically*
nest quantifiers; you just need some extra grouping to get past the
syntactic hurdle. /(?:a{3}){4}/ is legal and works, and in the same
vein /(?:^){4}/ would have to be legal.
>guess is the difference between erroring at parse time, versus
>optimization time.
No, I would expect /(?:^){4}/ not to error at all. The optimiser would
be free to reduce it to a single SBOL op, just as it is already free to
do that with /^{4}/.
>Historically I have done everything I could to get us out of special
>casing things based on the spelling of the pattern[1], and to instead
>use the optree representation instead, so doing the opposite here
>feels wrong. Although I am open minded about it.
There are some things that should be based on the parse tree of the
pattern, and others that should be based on the optree. The acceptability
of directly applying a quantifier is a syntactic matter that should be
based on the parse tree. The parse tree does not include whitespace
that is insignificant due to /x. Semantically, a quantifier is *always*
acceptable, so the optree is not a concern here. The optimiser may have
things it can usefully do with quantifiers, but those should be limited
to optimisation. The optimiser should work entirely on the optree.
-zefram
Thread Previous
|
Thread Next