Me writes:
: [modified repost due to warnock's dilemma]
:
: Would something like these DWIM?
:
: # match pat1 _ pat2 and capture pat2 match:
: / pat1 { ($foo) = / pat2 / } /
Yes, though I think we'll see people doing it more like this:
/ pat1 ( pat2 ) { $foo = $-1 } /
We might allow something like
/ pat1 $foo=( pat2 ) /
as a shorthand for that. But in the general case, the closure can
put the value anywhere, and this will be particularly important for
building parse trees.
: # match pat1 _ 'foo bar':
: / pat1 { 'foo bar' } /
Probably not. I can think of several other good uses for return values
from inner closures, such as building a parse tree. But at the moment
I'm thinking that the return value will be ignored. If so, {'foo bar'}
might be the way to inline comments in place of (?#foo bar).
: # match pat2 if not pat1
: / { ! /pat1/ } pat2 } /
Same issue. You can always write / { /pat1/ or fail } pat2 /. I don't
think the return of the closure will be interpreted as a boolean.
Closures will be used for side effects, and I'd hate to see a lot of
closures ending in a cryptic C<0;>. It's better to make the assertions
explicit. Could even have a unary "fail unless" operator:
/ { assert /pat1/ } pat2 } /
There might be a better word than assert.
: # match pat2 if pat1 behind
: / { .lookbehind /pat1/ } pat2 } /
Sure, presuming .lookbehind knows how to fail. But <after: pat1> is
much more readable, I think.
Larry
