Merry Christmas to you all!

We use => for pairs, but also for something very different: named
argument binding. Yes, pairs are used for that, but that introduces
problems. The most important problem, that pairs sometimes have to be
passed, and sometimes have to be named arguments, is fixed with a hack
that to me, just doesn't feel right: if the pair is literal and not
inside grouping parens, it's a named argument. Otherwise, it's a pair.
Especially with the function of the () glyphs being different between
with and without whitespace after the subname, this can be very

I'd like pairs and argument binding to be two different things. With
different syntaxes.

The next thing I thought was: hey, argument *passing* is actually
*binding* to variables in the sub, so why not use the := operator? That
works very well, because binding as an expression makes no sense anyway,
it being a language thing. And luckily, named arguments are also a
language thing, so that works out:

        named_arg := $value,
        other_arg := $value,

Incidentally, that happens to be the same as Visual Basic's syntax for
named arguments. But let's quickly forget that.

Using := for this also fixes the problem of having to use *, which feels
like a hack, to use a single stored named argument:

    sub f ($foo) { ... }

    my $a = foo := $bar;  # named argument
    my $b = foo => $bar;  # pair

    f($a);  # f($bar);
    f($b);  # f(:foo($bar));

Pairs can still go into the slurpy *%hash, and I propose :[EMAIL PROTECTED] for
catching unknown named arguments. An array, because accessing them by
key individually makes no sense: they're named arguments.

Unary := can perhaps convert a hash to named arguments, should you ever
feel a need to pass a hash that way. f := %foo;


Reply via email to