There is, but it's a different kind of pattern matching:
if @*ARGV ~~ / <,> -f <,> (.*?) <,> / {
$0 .= absolute_filename;
}
Of course, that only works if you're allowed to modify the source
through the $# variables. I think you are, but I'm not certain.
This is a good example of how silly the current array matching
semantics are. You'd get a match for this call, because of
"carelessness" in writing the rule.
davesprog foo - f file
Because elements are implicitly concatenated together. The "correct"
way to write the rule is:
/ <,> - <!,> f <,> (.*?) <,> /
Isn't that dumb?
Here's what I counterpropose: matching against arrays treats each
element of the array as a single character. <()>-assertions make the
current character their topic. There is no <,>; it's implicit in the
character-element unification. Here's the new regex:
/ <( $_ eq '-f' )>. (.) /
This method makes more sense for a list of tokens, too.
We could shuffle around the special assertions to give shorthands for
these presumably common constructs:
<( ... )>.
<( $_ eq ... )>.
<( $_ ~~ /.../ )>.
The last one is the most important. It allows you to connect regexes
on a stream to regexes on an element of the stream. Possible
shorthands for those, respectively:
<+( ... )> # treating an assertion as a char class
<'...'> # hmm, already takes, maybe we could
# make a special case because it
# doesn't make much sense for
# nonstrings
</.../> # obvious
> Would this actually work, or would it stop at the first elem that
> doesn't match ("-f", ::Item)?
If by "stop" you mean "die", yes it would stop.
> Is there some way to associate alternate codeblocks for different
> patterns (i.e. local anonymous MMD)?
As Austin points out, that's called "given". I'll also point out that
if we have lookahead in "for" (a feature that I think is best reserved
for third-party modules):
for @*ARGV -> $cur, ?$next is rw {
if $cur eq '-f' {
$next .= absolute_filename;
}
}
Which isn't as slick as a pattern matching approach, but it gets the
job done without having to use indices.
Luke
Oh, that's a clever way to process arguments. A module could probably
turn that into a nice declarative option parsing library.
Unfortuately, it the form you've written above, that doesn't work.
That's because process_arg does not have a well-defined arity, so
"for" doesn't know how many elements to pull of the list each time.
In order to do that correctly, there would have to be some very fine
communication between for and the signature pattern matcher.
I could definitely see a library doing this though:
getopts @*ARGV,
-> '-f', Str $f is rw {...},
-> '--quux', Str $arg1, Str $arg2 {...},
-> $ { }; # ignore
It is likely doable without any magic too wicked, too.
Luke
>>Would this actually work, or would it stop at the first elem that
>>doesn't match ("-f", ::Item)?
>
> If by "stop" you mean "die", yes it would stop.
not what I wanted :-(
>>Is there some way to associate alternate codeblocks for different
>>patterns (i.e. local anonymous MMD)?
>
> As Austin points out, that's called "given". I'll also point out that
> if we have lookahead in "for" (a feature that I think is best reserved
> for third-party modules):
>
> for @*ARGV -> $cur, ?$next is rw {
> if $cur eq '-f' {
> $next .= absolute_filename;
> }
> }
>
> Which isn't as slick as a pattern matching approach, but it gets the
> job done without having to use indices.
What happens if I simply abandon the attempt at anonymous MMD and use a
That doesn't seem sufficiently general. I'd rather see some context
that can apply a signature to the head of a list and treat the
"unslurped" part as unmatched. Maybe a "for" loop could be taught
to supply such a context, or a "when". Or maybe it's just the result
of embedding a sig inside a rule, or of matching a sig using ~~.
Basically, we just have to find a way to treat the sig as a pattern
that isn't anchored at the end.
Larry
Could the sharp end of a pipe be taught to do this?
I suggested something like this before but Luke pointed out that it
was adding unnecessary DWIMiness. Perhaps this use case could revive
the idea:
Brad
--
There are two things that will blemish a retainer, these are riches and
honor. But if one remains in strained circumstances he will not be
marred. -- Hagakure http://bereft.net/hagakure/