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; }


   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";


   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

Jonathan "Dataweaver" Lang

Reply via email to