Associative parameters

[Bill Baxter]

Pragma wrote:
> Just my $0.02 here: Lately I have been doing a lot more python 
> programming and I've found it's named arguments to be a good substitute 
> for overloading.  It's not perfect replacement, but it does have its 
> advantages.  I have yet to find it
> problematic.

I think there's not much other way you could implement overloading in a 
language like Python where there are no declared types.

def foo(x):
    # do one thing
def foo(y):
    # do another thing

How's the interpreter supposed to decide which one you mean?  You could 
overload on the number of arguments I suppose, but by doing that you'd 
mostly just lose the ability to unambiguously refer to functions by name 
(which bites us even today in D2.0  -- callback=&foo;  ... but which 
foo?).  Variable numbers of arguments can be reasonably implemented 
using defaults.

But when you do have type info that you can overload on, it's a whole 
different thing.

> But from what I can tell, named arguments are no more or less 
> problematic than overloads mixed with default arguments. Right now, it's 
> possible to create two or more overloads that can be called the same 
> way, resulting in an ambiguity that is easily flagged by the compiler.
> Named arguments just provide another way to make the same kind of 
> mistake, so the developer must be no more aware than before.
> 
> void foobar(int d);
> void foobar(int a=0,int b=0,int c=0,int d=0);
> foobar(d=42); // which one?
> foobar(69);   // which one?

I like the idea of named parameters too, but the contrarian's argument 
is that even if the compiler can catch all the errors, it still adds a 
lot of complexity to the language.  Especially since there are already 3 
ways to overload functions (by arg types, by number of args, and with 
defaults).

To make it feasible I think we're first going to have to introduce a 
special syntax for keyword arguments.  Any D code that exists today 
should continue to behave the same as it does now.  Suddenly giving 
meaning to all parameter names would be a catastrophe.

In Lisp, for example, all keyword arguments follow a &key sigil:
    http://www.gigamonkeys.com/book/functions.html

(defun foo (bar &key (a 0) b c)
    (list bar a b c))
(foo)                   ==> ERROR missing required argument 'bar'
(foo 99)                ==> (99 0 NIL NIL)
(foo 99 :a 1)           ==> (99 1 NIL NIL)
(foo 99 :b 1)           ==> (99 0 1 NIL)

Something like that could probably be made to work for D.  I think Lisp 
also requires you to supply the keyword when you call it.  I.e.
(foo 3 2 1 0) doesn't work.  You have to name the keyword arguments. 
Even if that's not Lisp's rule, it makes sense for D, since it would cut 
down a lot on overload ambiguity issues.

In D you'd also be required to supply default values for all keyword 
args.  Be

So for D we could do something like:

void foo(int bar, :key: int a=0, int b=0, int c=0) {
    writefln("%s %s %s %s", bar,a,b,c};
}

The ":key:" token is just an example.  Could be any other unambiguous token.

--bb