Front page | perl.perl5.porters |
Postings from July 2016
hv@crypt.org wrote: > we have exactly that >concept with the flags and /(?f:...)/ construct. It doesn't make sense as a flag in this way. The existing flags affect the interpretation of individual regexp elements, so turning them on and off locally has obvious semantics. But the script-run feature affects the meaning of a whole group. /(?a:\w)(?a:\w)/ means the same thing as /(?a:\w\w)/, but /(?S:\w)(?S:\w)/ wouldn't mean the same thing as /(?S:\w\w)/. It does need affordance to apply it to an arbitrary group, but flag syntax is the wrong way to get that. I therefore favour the /(*sr:...)/ type of syntax. >That also implies it can be locally disabled: > /(?S:\w+ (?-S:\w) \w+)/ Still doesn't make sense as a flag, but there's room for another grouping operator that makes its content invisible to the immediately-surrounding script-run constraint. /(*sr:\w+ (*srhide:\w) \w+)/. >I think the first (where +S is introduced when it is already active) >should be a noop - the same script should still be required. > >I think the second (where +S is introduced in a -S scope, itself within >a +S scope) should permit a new script. These are the obvious semantics for nesting (*sr:...) and (*srhide:...). >I wonder whether the next request will be a variant that overrides /./ >to be equivalent to /(?S:\W|\w)/. What's that supposed to achieve? Any single character automatically satisfies the script-run constraint. >Should the proposal also affect uses of \w inside character classes? Yes. The script-run constraint should apply to the sequence of characters actually matched (except for characters hidden in a nested (*srhide:...)), regardless of the constructs used to match them. -zeframThread Previous | Thread Next