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

2006-10-11 Thread 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 (if the
block doesn't take parameters) or C (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
C 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


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

2006-10-11 Thread 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


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

2006-10-11 Thread 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 > 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