s[pattern] = { doit } illegal, why?

[Jonathan Lang]

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

[Larry Wall]

On Wed, Oct 11, 2006 at 05:55:45PM -0700, Jonathan Lang wrote:
: 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[(\d+)!] = "{ my $num = 1; $num *= $_ for 0..$0; return $num; }"

s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; }.()
s[(\d+)!] = do { 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";

: }

s:s:g[(\w+): (\d+) dB] = do
given @() -> [$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 }

s:s:g[<,> (\w+): (.+) <,>] = -> $key, $val { $key => $val }.(@())
s:s:g[<,> (\w+): (.+) <,>] = do for @().each -> $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.

Could do that too (and there's even precedent with attribute defaults),
but outlawing it (at least for now) keeps people from cargo culting
P5's s{foo}{bar} into P6's s{foo}={bar}.

Larry

[Larry Wall]

On Wed, Oct 11, 2006 at 06:29:00PM -0700, Larry Wall wrote:
: s:s:g[<,> (\w+): (.+) <,>] = -> $key, $val { $key => $val }.(@())

Hmm, that won't work, since @() is a single argument. It'd have to be one of:

s:s:g[<,> (\w+): (.+) <,>] = -> [$key, $val] { $key => $val }.(@())

s:s:g[<,> (\w+): (.+) <,>] = -> $key, $val { $key => $val }.(|@())

Larry

[Jonathan Lang]

In short, nearly every case where I'm looking to use a "raw" closure
can be handled almost as easily by prefacing it with C<do> (if the
block doesn't take parameters) or C<do given> (if it does). A bit
more wordy than I'd like, but acceptable; it still reads well.
Although I'd recommend pointing this option out in S05, right after
you say that s[pat] = { doit() } won't work.

On 10/11/06, Larry Wall <la...@wall.org> wrote:
> s:s:g[<,> (\w+): (.+) <,>] = do for @().each -> $key, $val { $key => $val }

Minor point: Since the right side gets called for each left-side
match, isn't the C<.each> redundant? For that matter, isn't the
C<for> overkill as well? C<@()> will only ever have two elements per
call, after all...

> : 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.
>
> Could do that too (and there's even precedent with attribute defaults),
> but outlawing it (at least for now) keeps people from cargo culting
> P5's s{foo}{bar} into P6's s{foo}={bar}.

This would be the "ye olde code doesn't do a text substitution
anymore" issue, right? And there _is_ still the possibility of
permitting it in some later subversion of Perl 6, once people have
gotten Perl 5 out of their systems...

--
Jonathan "Dataweaver" Lang