Here's some more commentary to draft zero of the capturing semantics
(thanks, Damian!), based partially on PGE's current implementation.
On Mon, May 09, 2005 at 10:51:53PM +1000, Damian Conway wrote:
> [...]
> =head2 Nested subpattern captures
> [...]
> There may also be shortcuts for accessing nested components of a subpattern,
> specifically:
>
> # Perl 6...
> #
> # $1----------------------------- $2--------- $3--------------------
> # | $1.1 $1.2------------- | | | | $3.1 $3.2---- |
> # | | | | $1.2.1 | | | | | | | | | |
> # | | | | | | | | | | | | | | | |
> m/ ( The (\S+) (guy|gal|g(\S+) ) ) (sees|calls) ( the (\S+) (gal|guy)
> ) /;
>
> but this has not yet been decided.
After thinking on this a bit, I'm hoping we don't do this -- at least not
initially. I'm not sure there's a lot of advantage of C< $1.1 > over
C< $1[0] >, and one starts to wonder about things like $1.$j.2 and
$1[$j].2 and the like.
> =head2 Quantified subpattern captures
> [...]
> If a subpattern is directly quantified using the C<?> or C<??> quantifier,
> it produces a single C<Match> object. That object is "successful" if the
> subpattern did match, and "unsuccessful" if it was skipped.
I'm not sure that PGE has these exact semantics for C<?> yet -- I'll have
to check.
> =head2 Indirectly quantified subpattern captures
> [...]
> A subpattern may sometimes be nested inside a quantified non-capturing
> structure:
>
> # non-capturing quantified
> # __________/\_________ __/\__
> # | || |
> # | $1 $2 || |
> # | _^_ ___^___ || |
> # | | | | | || |
> m/ [ (\w+) \: (\w+ \s+)* ]**{2...} /
>
> [...] In Perl 5, any repeated captures of this kind:
>
> # Perl 5 equivalent...
> m/ (?: (\w+) \: (\w+ \s+)* ){2,} /x
>
> would overwrite the previous captures to C<$1> and C<$2> each time the
> surrrounding non-capturing parens iterated. So C<$1> and C<$2> would
> contain only the captures from the final repetition.
>
> This does not happen in Perl 6. Any indirectly quantified subpattern is
> treated like a directly quantified subpattern. Specifically, an
> indirectly quantified subpattern also returns an array of C<Match>
> objects, so the corresponding array element for the indirectly
> quantified capture will store an array reference, rather than a single
> C<Match> object.
It might be worthwhile to add a note here that one can still get
at the results of the final repetition by using $1[-1] and $2[-1].
> =head2 Subpattern numbering
> [...]
> Of course, the leading C<undef>s that Perl 5 would produce do convey
> (albeit awkwardly) which alternative actually matched. If that
> information is important, Perl 6 has several far cleaner ways to
> preserve it. For example:
>
> rule alt (Str $n) { {$/ = $n} }
>
> m/ <alt tea> (don't) (ray) (me) (for) (solar tea), (d'oh!)
> | <alt BEM> (every) (green) (BEM) (devours) (faces)
> /;
If the C< alt > rule is accepting a string argument, the match
statement probably needs to read
m/ <alt: tea> (don't) (ray) (me) (for) (solar tea), (d'oh!)
| <alt: BEM> (every) (green) (BEM) (devours) (faces)
/;
> =head2 Repeated captures of the same subrule
>
> =head3 Scalar aliases applied to quantified constructs
> [...]
> A set of quantified I<non-capturing> brackets always returns a
> single C<Match> object which contains only the complete substring
> that was matched by the full set of repetitions of the brackets (as
> described in L<Named scalar aliases applied to non-capturing brackets>).
At present, PGE isn't working this way -- aliased quantified non-capturing
brackets returns an array of match objects, same as other quantified
structures. This can be changed, but I kind of like the consistency
that results --
"coffee fifo fumble" ~~ m/ .*? $<effs>:=[f <-[f]>**{1..2} \s*]+ /;
PGE currently gives $<effs> an array of matches, same as for the
other capturing constructs. If someone wants to capture the full
set, it's easy enough to do
"coffee fifo fumble" ~~ m/ .*? $<effs>:=[ [f <-[f]>**{1..2} \s*]+ ] /;
and it's pretty clear what was intended.
> =head3 Array aliasing
> =head3 Hash aliasing
> =head3 External aliasing
> =head2 The C<:parsetree> flag
> etc.
At the moment PGE doesn't support these, and probably won't until
they're actually needed in the course of developing the compiler
(or until someone adds them).
> [...]
> Moreover, the C<:parsetree> flag overrides the exemption of C<< �name� >>
> subrule calls, so they act as if they were C<< <name> >> calls instead. They
> generate C<Match> objects, and those objects are also appended onto the
> surrounding scope's C<Match> array.
Do we still have the C<< �name� >> syntax for rules? S05 doesn't
mention it, A05 mentions it as a non-capturing subrule but I think
we've since changed to C<< <?name> >> instead. If we don't have
C<< �name� >> I'll adjust S05/A05 accordingly.
Pm
