While I agree with most of the changes made to the s[]... notation,
there's one oddity that I just spotted:
S05 says:
This is not a normal assigment, since the right side is
evaluated each time the substitution matches (much like the
pseudo-assignment to declarators can happen at strange times).
It is therefore treated as a "thunk", that is, as if it has
implicit curlies around it. In fact, it makes no sense at all
to say
s[pattern] = { doit }
because that would try to substitute a closure into the string.
So I can't say something like
s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; }
or
s:s:g[(\w+): (\d+) dB] =
@() -> $name, $num {
$num = exp($num/10, 10);
say "$name has excessive wattage: $num Watts" if $num > 1000000;
"$name: $num Watts";
}
or
s:s:g[<,> (\w+): (.+) <,>] = @() -> $key, $val { $key => $val }
? That seems like a pretty significant limitation. Could closures be
an exception to the "implicit curlies" rule? That is: if you supply
your own closure on the right, the substitution algorithm accepts it
as is; if you supply anything else, it gets wrapped in a closure as
described.
--
Jonathan "Dataweaver" Lang
