Larry discounted RFC261 in A5, but I think there's some good in it. The
biggest problem is not that it's hard to do in Perl6, but that 80-90% of
it is ALREADY done in Perl5! Once you peel away that portion of the RFC,
you get to Perl5's limitations and what Perl6 might do to support these
things.
NOTE: My examples are unchecked, so they should be considered
pseudo-code.
# RFC261
match ($a) = @foo;
# Perl5
($a) = @foo;
#RFC261
match { 'Joe' => ? } = $h or die "Hash does not contain Joe";
#Perl5
scalar(grep { $_ eq 'Joe' } keys %$h) or die ...
# This one states its own solution
# Equiv to scalar(grep { $_ == 1 } @list)
match (..., 1, ...) = @list;
# No idea what this is supposed to do. I think $_[$_] is meant to work
# in a way it doesn't ($_ will be a value, not an index).
# Pretty close to ($idx) = grep { $_[$_] == 1 } @_; $b = $_[$idx+1];
match (..., 1, $b) = @_;
# However, I want to suggest that Perl6 closures on grep and map should
# be considered anonymous methods on the implied loop itself, so that we
# can call methods like .index or .prev or .next (look ahead/behind), etc.
# This gets sticky in some situations, but it would be invaluable, so it's
# worth the effort, IMHO.
# RFC
# It gets worse! This gives the value associated with a key matching the
# regular expression a*b:
match { /a*b/ => $value } = \%h;
#Perl5
# The RFC does not account for multiple matches
# (presumably we just take the first)
($value) = map {$h{$_}} grep {/a*b/} keys %h;
# RFC
# And if you want to know what the key was:
match { $key = /a*b/ => $value } = \%h;
# Perl5
($key,$value) = map {($_,$h{$_})} grep {/a*b/} keys %h;
# RFC
# What if you want to grab out the index? This is like
# ($i) = grep { $list[$_] =~ /foo/ } 0..$#list
match ( $i => /foo/ ) = @list;
# Perl5
# As suggested above
# Perl6
# See my previous comment on closures of this type
grep {/foo/ && $i = .index} @list;
Sorry, it's time for me to go meet someone, but I think the rest of the
RFC just gets into two cases. One involves some funky OO stuff that I'm
not going to touch on here. The other is the idea of matching sub-lists,
which would be the place for some methods inside of grep and map that
support look ahead and behind.
I hope others will take up this line of thought. Improved list
manipulation can only be a good thing, IMHO.
