In a message dated Mon, 9 Dec 2002, Adam D. Lopresto writes:
> Looks to me like with a few appropriate methods, you have left-to-right
> ordering for free.
>
> (@foo, @bar) := @a
> . grep { $_ > 0}
> . sort { $^b <=> $^b }
> . part [/foo/, /bar/];
Yes, exactly.
> Of course, that means that grep and sort and part are all methods of the Array
> class, so the standard way to write them would be
>
> grep @a: {$_ > 0};
>
> instead of
>
> grep {$_ > 0} @a;
>
> Hmmmm. Odd. I'm guessing it wouldn't be possible to extend the indirect
> object syntax to allow
>
> grep {$_ > 0} @a:;
Eh, here you give a nod to backwards compatibility (not to mention to
removing extraneous symbols), I think, and define universal multimethods
taking a block and an array or an array of blocks and an array (or an
array of rules and an array, etc.).
That way, all the following would work:
(@foo, @bar) := @a.grep{foo}.sort{byBar}.part[/foo/, /bar/];
# do you need parens around the parameters?
(@foo, @bar) := part [ /foo/, /bar/ ]
sort byBar
grep {foo} @a;
(@foo, @bar) := part :(
sort :(
grep :@a {foo})
byBar)
[/foo/, /bar/];
That last is atrocious--but the fact that it is available doesn't mean
that it should be encouraged.
> (object can go anywhere in argument list, so long as it's marked with a
> :. But now I'm trying to speculate about Larry's colon, something best
> left to others).
That would allow
(@foo, @bar) := part [ /foo/, /bar/ ] :(
sort byBar :(
grep {foo} :@a));
as well as
(@foo, @bar) := part [ /foo/, /bar/ ] :(
sort :(
grep :@a {foo})
byBar);
or
(@foo, @bar) := part :(
sort {foo} :(
grep {foo} :@a))
[ /foo/, /bar/ ];
This is really awful, IMHO. I say just define the multimethod letting you
rearrange the arguments back to the old style and get on with it.
Extending colon to allow it to move willy-nilly through the argument list
may be useful in simple cases, but if nested will be incomprehensible.
This is exactly the same as natural languages, by the way--we can deal
with one or two levels of interior clause nesting, but beyond that we lose
track of what clause is playing what role. The question becomes, is
moving the indirect object around useful enough in the small
comprehensible cases that we're willing to accept the ability to write the
large incomprehensible ones?
> But somehow it seems like an increase in readability, especially if things were
> renamed. Imagine renaming "grep" to "where" or "suchthat". And then the
> antigrep can be "except".
As synonyms, or total renamings for the array-method form? I neither like
populating the language with superfluous names, nor do I like having to
remember "C<grep> is C<suchthat> when used as an array method", which
you'll have to do if you try to transform the functional style to the
method-pipeline style.
Trey
--
I'm looking for work. If you need a SAGE Level IV with 10 years Perl,
tool development, training, and architecture experience, please email me
at [EMAIL PROTECTED] I'm willing to relocate for the right opportunity.
