Dave Storrs wrote:
> I admit I'm a bit nervous about that...so far, I'm completely sold on
> (basically) all the new features and changes in Perl 6, and I'm eagerly
> anticipating working with them. But this level of change...I don't know.
> I've spent a lot of time getting to be (reasonaly) good at Perl regular
> expressions, and I don't like the thought of throwing out all or most of
> that effort.
You won't be, Dave. Every feature you've learned is still there (except the
few insane ones ;-). You just have to learn the new syntax for them. And that
shouldn't be too hard since we carefully rationalized that new syntax --
specifically to make it easier to learn, remember, read, and predict.
> 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. ;-)
> For now, I'm just going to defer worrying about it until I see Exegesis 5,
> since past experience has shown me that there is a good chance that all my
> fears will be shown to be groundless once concrete examples are being
> demonstrated.
Good advice.
> 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". You probably want:
s:3rd:4th:5th/foo/bar/
> The u1-u3 mods all say "level 1 support". I assume this was a typo, and
> they should go (u1 => 'level 1', u2 => 'level 2', u3 => 'level 3').
Yes. That's being corrected on perl.com RSN.
> Can modifiers abut the delimiter?
>
> s:3x /foo/bar # most (all?) examples looked like this
> s:3x/foo/bar # is this legal?
Yes.
> -----------------
>
> Can we please have a 'reverse x' modifier that means "treat whitespace as
> literals"?
I'll talk about that with Larry. If he were to approve it, it might possibly
be :W
> 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.
> 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.
> / 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.
> When the entire match succeeds, the top-level node is returned as
> a result object.... The name of the result object is $0.
>
> If the name of the result object returned from a successful match is $0,
> where is the name of the currently-executing program stored?
In $*PROG or something like it.
> 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 ;-)
> / $2:=(.*?), \h* $1:=(.*) /
>
> Does this imply that $1, $2, etc are now read-write outside of regexen?
No.
> How are 'fail' and 'die' different inside a regex?
C<fail> initiates backtracking within the current regex.
C<die> throws an exception that will almost certainly propagate all the
way out of the regex.
> 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).
Damian
