Larry said:
> I haven't decided yet whether matches embedded in
> [a regex embedded] closure should automatically pick
> up where the outer match is, or whether there should
> be some explicit match op to mean that, much like \G
> only better. I'm thinking when the current topic is a
> match state, we automatically continue where we left
> off, and require explicit =~ to start an unrelated match.
So, this might DWIM:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1
{ ($foo) = / pat2 / }
pat3 /
What is the meaning of a string returned by some code
inside a regex? Would this DWIM:
# match pat1 _ 'foo bar' _ pat2:
/ pat1 # white space is ignored
{ return 'foo bar' } # conserve whitespace
pat2 /
What if there were methods on the match state to
achieve regex extensions:
s/ { .<; /c/ } ei / ie /; # wierd look behind?
and so on:
/ pat1 { .>; /pat2/ } pat3 /
/ { .! and .<; /pat1/ } pat2 } /
--
ralph
