On Tue, Dec 17, 2002 at 02:51:04PM -0500, Dan Sugalski wrote:
> At 9:54 AM -0800 12/17/02, Michael Lazzaro wrote:
> >We _must_ (for some value of "must" that is real close to being a
> >100% drop-dead requirement) support --> (L2R), in the form of
> >
> > @a.grep( {...} )
> > .map( {...} )
> > .sort;
>
> Those are simple method calls, so there's no reason we shouldn't
> support them, though they will *only* work if each returns an actual
> array, rather than a list.
Question on this: for me, one of the trickiest things when teaching
Perl5 has always been explaining the difference between an array and a
list, when you need one versus the other, why they aren't precisely
the same, and where the differences are.
What exactly are the advantages of having both in Perl6? Is it
possible that we could put them together and have only one or the
other without losing anything (that we aren't willing to lose)?
> @b = (*@a, *@b, foobar()) grep {} map {} sort {};
>
> That can't work as methods of the list, unless we're wildly
> redefining how lists work, which I don't think we're going to do.
I don't know enough to see why this is a problem. Can you explain it?
> *That's* the sort of way, the L2R way, that I'd argue against.
> Shifting directions in mid-stream is, well, really tough for us old
> codgers.
Mid-stream in terms of the work that's been done on Parrot or in terms
of your programming experience? i.e., are you saying that it would
require major redesign and recoding on the existing engine, or that it
would be hard to get used to having it in the language?
> function calls. To forbid
>
> @b = sort {} map {} grep {} @a;
>
> is the same as forbidding
>
> @b = sort({}, map({}, grep({}, @a)));
>
> which I think would be... unwise. As would chopping sort/map/grep and
> friends from the language entirely. One of the hallmarks of perl is
> its richness, and I think losing that would be ill-advised.
Indeed.
--Dks
