On 12/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> foo(
> named_arg := $value,
> other_arg := $value,
> );
I'll point out that Joe's argument is completely moot, because you're
not using $s on the named arguments. As a matter of fact, we could
double up the := symbol as both binding and named arg passing, using a
=>-like heuristic (\w-only means it's a named arg). That kind of
symbol overloading might be too confusing (but as you point out, no
more confusing than the pair syntax).
> 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);
Okay, it seems like I have to argue this every time it comes up. In
my "demagicalizing pairs" proposal, the * was by linguistic design,
not a way to get around a problem that the proposal had. One might
even say that it was the main reason for the proposal.
The point was that you should know when you're passing a named
argument, always. Objects that behave specially when passed to a
function prevent the ability to abstract uniformly using functions.[1]
Let's say you're tossing around a list of these "named argument"
objects, constructing it for a call to a function with a very
complicated interface. You see:
sub sort_nameds([EMAIL PROTECTED]) {
return () unless @nameds;
my $pivot = shift @nameds;
my @pre = grep { .name lt $pivot.name || .name eq $pivot.name
&& .value < $pivot.value } @nameds;
my @post = grep { .name ge $pivot.name && (.name ne
$pivot.name || .value >= $pivot.value) } @nameds;
return (sort_nameds(@pre), $pivot, sort_nameds(@post))
}
And you say, hmm, interesting, there is some code duplication there.
So you refactor:
sub sort_nameds([EMAIL PROTECTED]) {
my sub cmper($x, $y) {
$x.name lt $y.name || $x.name eq $y.name && $x.value < $y.value
}
return () unless @nameds;
my $pivot = shift @nameds;
my @pre = grep { cmper($_, $pivot) } @nameds;
my @post = grep { !cmper($_, $pivot) } @nameds;
return (sort_nameds(@pre), $x, sort_nameds(@post));
}
But there is an error there. You can't pass $pivot (or $_) into cmper
inside those greps, because they will try to bind to the named
arguments of cmper, instead of passing proper as you'd like them to.
You might say "okay, we'll just invent a syntax that says 'pass these
as objects, not as named args'". Maybe \$arg or whatever. Now you
have to know what's in your variables to abstract them properly. This
is pretty much the opposite of the idea of polymorphism, which says "I
can do something to what you give me, no matter what it is". And we
all know by now, hopefully, that once you're beyond scripting,
polymorphism is a good thing.
Convenient, natural syntax is good, but it must not hinder our ability
to abstract. You've got to tell the compiler when you're passing a
named argument. The * syntax to pass a pair was very intentionally
*not* a hack.
As far as the rest of the proposal goes...
The ideas of pairs and named arguments have been separate ever since
we demagicalized them; we've just overloaded their syntax. What you
propose gives each its own syntax, but instead overloads the syntax of
binding to named arguments (which is indeed conceptually closer). But
you lose something important in the process: The :foo($bar) syntax.
I, for one, like writing my named arguments with that style more than
I do with the => style.
So I'd be happy if you stole :foo($bar) for named args and left only
=> for pairs, but that might make people who write hashes with
:foo($bar) pairs unhappy.
All in all, I think the syntax overloading here is a pretty fair
compromise. Maybe it would make you feel less uneasy if you thought
of it as syntactic overloading rather than a special interpretation of
pairs.
[1] This is one of my quibbles with junctions, too.
Luke
