On 2003-01-17 at 17:17:03, Joseph F. Ryan wrote:
> >But as I see it, the real problem being solved by the new syntax
> >is that grep and map can exist solely as methods on some class
> >in the inheritance tree of @arrays, no global functions required.
> >That is a Good Thing.
> >
>
> In your opinion. I'll still want to be able to write 1-liners and
> short scripts. I'm sure perl6 will still be used for things other
> than large applications. Is it such a sin to want the old syntax?
Of course not. Nor is anybody arguing against the utility of
1-liners and short scripts, or the desirability of maintaining
Perl's usefulness for such.
> Even if the definition for grep lives in a method, why couldn't
> there also exist a global function that looks like:
>
> sub grep(&code,@array) {
> @array.grep(&code);
> }
In that scenario, if you wanted to alter the behavior of grep, you
could probably get away with just modifying the array method, but
some modifications might require changing the function, too. Having
to change something in two places is generally a bad thing.
> Or even if this function does not exist, there's nothing stopping
> the compiler from simply aliasing:
>
> grep {} @array;
Yes, but the goal is to avoid special cases. If these:
grep {expr} @array
map {expr} @array
become these:
@array.grep({expr})
@array.map({expr})
that violates the standard interpretation of such sequences. The
"indirect object" syntax (assuming that were inferred despite the
lack of a colon) would instead interpret them as this:
{expr}.grep(@array)
{expr}.map(@array)
While if we inverted the IO interpretation of the syntax, then this:
print $STDERR foo
would become this:
foo->print($STDERR)
What we're looking for is a way to keep something close to
the old syntax, but in a more generally applicable way.
Why? Because general rules are, in general (:)), better than special
cases, simply because they result in less stuff to remember. It's true
that you often have to violate that principle to get good usability, and
Perl is the archetypical example of willingness to do so, but that doesn't
mean that the principle itself is bad. It just can be overdone
(and TCL would be my candidate for the archetypical example of overdoing
it).
All that said, one other thing for both sides of this argument to remember
is this: if the final syntax is not to our liking, then there's
nothing to stop us from writing our own - as a global function or whatever.
And there's likely to be a module that supplies the alternative syntax
anyway, possibly even bundled with the distribution.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
