In a message dated 27 Aug 2002, Uri Guttman writes:
> >>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> On 27 Aug 2002, Uri Guttman wrote: : and quoteline might even
> LW> default to " for its delim which would make : that line:
> LW> :
> LW> : my ($fields) = /(<quotelike>|\S+)/;
>
> LW> That just looks like:
>
> LW> my $field = /<shellword>/;
>
> where is the grabbing there? if there was more than just shellword would
> you have to () it for a grab? wouldn't that assign a boolean like perl5
> or is the boolean result only returned in a boolean context?
Note--no parens around $field. We're not "capturing" here, not in the
Perl 5 sense, anyway.
When a pattern consisting of only a named rule invokation (possibly
quantified) matches, it returns the result object, which in boolean
context returns true, but in string context returns the entire captured
text from the named rule (so, one hopes that the C<shellword> rule
captures only the quoted text, not the quotes surrounding it).
I think this is more generalizable. I believe that if one matches an
arbitrary rule which does not contain capturing parentheses, it returns
the result object as well, which should contain the entire match (as if
one put parens around the entire thing). Correct?
So:
my $vers = _ /<after Perl \s*> 6/;
should cause $vers to contain either "6" or "". A successful match object
is true in boolean context, so
my $vers = /<after Perl \s*> \d/;
would cause $vers to be true, even if the digit matched was zero.
Here's an interesting one:
my $vers = _ /<after Perl \s*> \d/; # Stringify...
print "yes!" if $vers; # ... and booleanize
If $vers contained "0", would it still be true? That is, does the "is
true" property of the result object survive stringification? It might be
useful if it did. On the other hand, of course, one can also imagine:
my $flag = _ (/<after ^^ debug \s* = \s*> <[01]>/
or die "No debug setting!");
print "yes!" if $flag;
where one would want the truth value to follow old conventions. Perhaps
you could write:
my $flag = /<after ^^ debug \s* = \s*>
[ 0 :: { $0 is false }
| 1
]/;
But then you have no way short of another string comparison for teasing
out the difference between a failed match and a zero match, which is what
we were trying to get away from.
Maybe I'm just making this too complicated....
> what happens to $field if no match was found? undef? the old boolean
> false of a null string wouldn't be good as that could be the result of a
> match. i assume undef could never be the result of a match unless some
> included perl code returned undef to the match object. then coder emptor
> would be the rule.
If the pattern doesn't match... will it return the undefined value, or
will it return a false (and stringwise empty) result object? I could see
it going either way, but a failed pattern result object is fairly useless,
isn't it?
> this is gonna make all the groups that copied perl5 regexes blow their
> lids. just think about all the neat canned regexes that will be
> done. like Regex::Common but even more so. we will need a CPAN just for
> these alone. full blown *ML parsers, email verifiers, formatted data
> extractors, etc.
More and more lately, I've been finding myself getting syntax errors when
I've wishfully put Perl 6 into my code. :-)
Trey
