The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can
still be called in a fashion similar to [1].  That would, I suspect,
satisfy everyone.
On Friday, December 13, 2002, at 03:07  AM, Piers Cawley wrote:
What's wrong with:

    class Array {
        method grep ( &block ) {
<snip>
    }

    sub grep (Object $obj, @*ary) { @ary.grep($obj); }

AFAICT, (modulo getting the laziness done right, this should allow
you to write)

    grep { ... } @ary;
    grep /.../, @ary;
The only issue is that it still treats C<grep> as a universal sub -- it's just giving you an identically named C<grep> method of Array, too. The ideal solution IMO is one that would remove C<map>, C<grep>, etc. _entirely_ from the main/core/Object, and leave it _solely_ as a method of Array. Not because C<grep> is inherently evil, but because that would give us a completely generic way to make other "piped" grep-style functions, like C<part>, without polluting the core namespace.

A (placeholder for a) R-to-L "dot-like" operator:

grep {...} <- @foo;

would be intended to be the *exact* equiv of

@foo.grep {...};

but with a reversed syntax for the invocant. So grep-like functions could be nested, and new ones could be created by making new methods of Array, AND we could get rid of the "specialness" of the Perl5 map/grep syntax -- the syntax isn't special to a few list-munging functions, it can be used for anything.

@out = sort <- map {...} <- grep {...} <- @in;

So it's almost what we had in Perl5, but more regular.

Of course, maybe '<-' is just spelled post-"given", and we're done:

@out = sort
given map { ... }
given grep { ... }
given @in;

Or would that be @out = .sort given .map ...etc...?

MikeL

Reply via email to