Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Friday, December 13, 2002, at 10:59 PM, Piers Cawley wrote:
>> map { .[0] }
>> sort { $^a[1] cmp $^b[1] }
>> map { $_ => some_transform($_) }
>> grep /.../, @array
>>
>> happily stays as it is; I fail to see what recasting that as
>>
>> map { .[0] } <-
>> sort { $^a[1] cmp $^b[1] } <-
>> map { $_ => some_transform($_) } <-
>> grep /.../ <- @array
>>
>> or any other 'noisy' suggestion buys us. It just seems like the wrong
>> kind of Laziness to me.
> <edited to fix a minor typo>
>
> My only concern is that the first implies (as it does in perl5) yet
> more special behaviors attached to the {...} brackets. Either "no
> comma is needed after a closure",
I think that's already a given; there's definitely discussion
elsewhere that takes that as read. And it's (prototyped) perl 5
behaviour, changing it to require a comma would be the Wrong Thing.
> or "no comma needed after the first arg of the specific functions
> named C<map>, C<grep>, ...
Definitely the Wrong Thing.
> I'm worried that in attaching even _more_ specialness to curlies
> (which are already highly (impossibly?) magical), we're setting
> ourselves up for some hurt down the road. It was OK in perl5, but I
> don't know if it's OK in perl6.
>
> Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
> syntax truly _needs_ to be in Perl6. It's true I use it all the time,
> but I can retrain to use L-to-R method calls with little effort.\
Personally I really don't like the L to R style; I know we've got it
for C<< for ... -> $a { ... } >>, but I can see the logic behind
that, otherwise L to R looks worryingly like C++ to me.
> If we have a post-given, e.g. C<map {...} given @a> or C<map {...} is
> given @a>, I think that gives us R-to-L without any special {...}
> rules at all.
No, just the addition of much ugliness to code for no gain in
readability. And one more area where Perl 6 fails to look like Perl 5
for no good reason.
