On 10 Dec 2002 17:25:34 +0000, Simon Cozens wrote:
> [EMAIL PROTECTED] (Peter Haworth) writes:
> > Fair enough; that simplifies things somewhat. However, you can't tell
> > how many arguments they take. How do you parse this without the
> > programmer specifying a great deal more than they're used to in Perl 5?
> >
> > $foo.bar $baz,$qux
>
> I see no block here. I'm just talking about passing a block to a method.
> You think I'm talking about a clever way of specifying a block's argument
> signature. I'm not.
Actually, I was accepting your point about block arguments not needing
parens, and generalising it to other kinds of arguments.
You want this to work:
@b = @a.grep { /\S/ };
instead of/as well as this:
@b = @a.grep( { /\S/ } );
I can agree that it's much cleaner looking. However, I want to be sure that
it doesn't introduce ambiguity. If the programmer wants $c on the end, and
writes this:
@b = @a.grep { /\S/ }, $c;
how does the compiler know whether $c is an argument to grep, or another
element to be assigned to @b?
Maybe a method can either be called with a parenthesised argument list, no
arguments (without parens), or with a single paren-less block. That also
gets around the chaining issue of:
@a.grep { /\S/ }.grep { .foo };
If the block is surrounded by implicit parens, that stops it getting
parsed as:
@a.grep( { /\S/ }.grep( { .foo } ));
Anyway, my point was that methods with paren-less arguments are either
ambiguous or greedy, unless you restrict the types of arguments this
applies to. If it's just blocks, them I'm fine with it.
--
Peter Haworth [EMAIL PROTECTED]
"The usability of a computer language is inversely proportional to the
number of theoretical axes the language designer tries to grind."
-- Larry Wall
