Dave Storrs yiked:
> Yikes. Ok, I obviously badly misunderstood that. I'll go back
> and reread it. So, can you provide an example of a "pattern nested
> within a closure", since I obviously didn't understand?
Sure:
m/ if { /<comment>? ::: <keyword>/ and print $0.{comment} } /
The C</<comment>? ::: <keyword>/> pattern is nested within a closure, so if it
backtracks over the :::, it fails, but that failure doesn't propagate out
to the enclosing C<m/ if {...} /> regex, as it would if it had been:
m/ if [ /<comment>? ::: <keyword>/ { print $comment } /
BTW, the reason the previous example *did* was because the closure executed an:
...or fail
after trying the nested regex.
> > > my &rx := /(xxx)/;
> > >
> > > Should that be a $ instead of a & on the rx variable?
> >
> > That ain't a variable, friend, that there's a gen-u-ine subroutine!
> > And it's being bound to a regex!!
> > (It's really just another way to give a regex a name ;-)
>
> Hmmm...what are the implications, here? The results of the match
> are passed as arguments to the func?
No.
> When you run the func, the regex is called?
Yes.
> Something else?
No.
> > > Can subroutines that aren't used in regexen use 'fail' to throw an
> > > exception? If so, how is it different from 'die' when used outside a
> > > regex?
> >
> > As I understand it, it isn't (currently).
>
> Just to be sure I understood: you meant that (A) yes, you can use
> fail in a subroutine outside a regex, and (B) if you do, it is no
> different from die. Is that correct?
As Larry pointed out, I had forgotten that C<fail> usually just returns
C<undef>, unless C<use fatal> is in effect, in which case it's like C<die>.
Damian
