> Maintainer: Bart Lateur <[EMAIL PROTECTED]>
> Date: 28 Sep 2000
> Last Modified: 1 Oct 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 348
> Version: 2
> Status: Frozen
> [can't find a good quote]
It'd be somwhat useful, I think, if you could return somthing like \matched
to
let paren-catching of the ?{} thingy have somthing other then "". (Remember,
a ref is always true.)
For example, that would let you parse somthing inside a regex that
requires a complicated decision only once, with only common
regexish stuff outside the regex itself.
Of course, auto-deref is evil, but you can't just use the return value, or
you couldn't return things that aren't true, but match.
> Replace the old implementation of (?{...}). Optionally, throw out all
> the "localizing" code. Do not set any special variables.
It'd possibly be useful if the entire regex was considered to be a scope
WRT lexicals. This lets you pass data around the regex without ugly
action at a distance (not much of a distance, anyway) without having
special rollback code -- any rollback needed either normal to local,
or it's not our job. It feels like "transactional variables" may be a
Good Thing here.
If you don't remember transactional varables, the idea is that
if the block succeeds, the variables retain their values as set in the
block,
and if the block dies, they get reset to their initial condition. The
difference
here is that the "exception" raised is when the block gets rolled back.
This requires thinking about it after the fact, which might be harder.
(but no harder then the current situation.)
Basicly, it'd be like the current local situation, but with explicit naming,
fitting in with a wider feature (just slightly different).
> The new feature should:
>
> have a zero width impact on matching in the regex
I think it would be very nice to have some sort of way of making the
bit 'o code have nonzero length. You can do that now, but it Isn't Pretty:
(?{somecodeeatingstuff; $numate=3}).{$numate}
This is fairly straightforward, but it's modifing a global varable, which is
a
Bad Thing.
The question, of course, is how to implement such a thing. An "eat" builtin
would be pretty cool, but alas, too useful a name for other things. <G>
> either succeed of fail, depending on the returned value as a boolean
> scalar: true means it's ok to continue, false means a veto, causing the
> regex to immediately backtrack.
And if you die, it will abort the regex?
Sorry to bring this stuff up after freeze -- I let my perl6 mail pile up too
much.
Oh, and assuming that I'm not making some stupid mistake, and with eat and
returning a ref, here's a killer app:
/([$matchingpairs])(.*?)(?{local $_=eat 1; $_ eq ${$matchingpairs[$1]} &&
\$1)/
It doesn't handle nesting thingies, but it's close.
(Assumes $matchingpairs{'('}=')'..., and $matchingpairs=join '', keys
%matchingpairs.)
-=- James Mastros
