On Fri, 7 Jun 2002, Damian Conway wrote:
> Dave Storrs wrote:
>
> > Somehow, this feels like we're trying to roll all of Prolog
> > into Perl,
>
> No. We're rolling in all of yacc/lex/RecDescent instead. ;-)
And this should reassure me _why_? *grin*
> > Just to verify, this:
> >
> > s:3rd /foo<3>/bar/
> >
> > ....would do the 3rd, 4th, and 5th, correct?
>
> Yes, but only if they were consecutive.And it would only replace them with a
> single "bar".
Sorry, my question was poorly phrased. Good, this did what I
expected it to do.
> > I am a little unclear on what the difference is between these two:
> > my @foo = <$rx>;
> > my @foo = m/<$rx>/;
>
> In Perl 5 terms, the first is equivalent to:
>
> my @foo; while (m/\G($rx)/gc) { push @foo, $1 }
>
> The first is equivalent to:
>
> my @foo; foreach (m/($rx)/g) { push @foo, $1 }
>
> That is, the first one is implicitly anchored to the end of the last match, so
> the matches have to be contingous. Whereas the second is unanchored, so the
> matches can occur anywhere in the string.
Urm...ok. I understand what you've said, (although you said
"first is equiv..." both times :>) but I guess I'll need to go back and
reread A5 to map your answer to the original text.
> > You could also use the {'...'} construct for comments, but then
> > you risk warnings about "useless use of a string in void context".
> >
> > Could we automagically turn off that warning inside such constructs, when
> > the only thing there was a string?
>
> Depends how much Larry wants to discourage inline comments, I guess. ;-)
> He's fairly strongly opposed to them.
I don't actually care one way or the other, I was just throwing
out a suggestion.
> > / pattern ::: { code() or fail } / # fails entire rule
> >
> > Farther down:
> >
> > A pattern nested within a closure is classified as its own rule,
> > however, so it never gets the chance to pass out of a {...}
> > closure.
> >
> > If I understand correctly, that means that this:
> >
> > / pattern ::: { $regex or fail } /
> >
> > would NOT fail the entire rule...correct?
>
> As I understand it, it definitely *would*.
>
> The code:
>
> $regex or fail
>
> has the $regex object in a boolean context, so it matches (if it can)
> and returns true or false. If it fails to match the C<or> fires off
> a failure, which causes the closure to fail, which causes the top-level
> regex to backtrack, whereupon it hits the :::, which causes the top-level
> rule to immediately fail.
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?
> > 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? When you run the func, the regex is
called? Something else?
> > 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?
Dave Storrs
