s[pattern] = { doit } illegal, why?
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 100;
$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
Re: s[pattern] = { doit } illegal, why?
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 100;
:
:$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 100;
$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
Re: s[pattern] = { doit } illegal, why?
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
Re: s[pattern] = { doit } illegal, why?
In short, nearly every case where I'm looking to use a raw closure
can be handled almost as easily by prefacing it with Cdo (if the
block doesn't take parameters) or Cdo 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 [EMAIL PROTECTED] 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
Cfor 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
