<div dir="ltr"><div>You can use a positional implementation for sure as long as the caller knows the argument names of the function it's calling at compile time.    You can't reduce it to the problem of resolving overloads for functions with purely positional arguments though, since that would require there being a single consistent mapping of <argument name> -> <argument position> across all of the overloaded ones. <br><br> You could have it try all of the overloads individually and see which ones matched, but by that point I think it's too complicated to be worth it.<br><br>It would also have the downside that it's harder to work out if two overloads are potentially ambiguous at the function declaration site (it's not too bad at the call site - if you have more than one match, it's ambiguous).  E.g. if I defined  f(float x=0.0, int y=0) and someone writes code with a call to f(y=0);  Now, if I added another overload f(int y=0), presumably the compiler wouldn't detect the overloads as ambiguous, since most ways of calling either are not, but then the call f(y=0) would break, since it's now ambiguous.  Not great for modularity.<br><br>I guess this got into a pretty academic discussion, but I do feel like keyword arguments and overloading don't play nicely together, and I do remember someone requesting keyword arguments at one point.<br><br><br>With polymorphism, what do you mean by polymorphism though?  I'd think of option types and type variables as one form of polymorphism among many, and probably the most natural one for a statically typed functional language.  <br><br>It comes up naturally - if you have a function like contains(array, array_element), then the type really should require that the arguments have types T[] and T.  The alternatives were to either special-case it in the compile (not supporting it for user-defined functions and forcing compiler changes for every addition operator), or by just giving on typechecking and letting the caller pass in anything as long as the first argument is an array.<br><br>The first would have been workable, but a bit limiting, and the second would have opened up a can of worms, since then it's possible to compare variables of completely different types and you have to work out what the equality rules are.  E.g., what does contains([1.0, 2.0], 1) do?<br><br></div>Anyway, with the avg([]) thing, my point was that the more features, the more corner cases come up.  Rejecting anything ambiguous is mostly the right thing to do I think.  In Swift/T it actually gets resolved to an int[], for the same reason that int A[]; A = []; passes type-checking - the expression [] has a wildcard in the type: *[].<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 10, 2015 at 11:40 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote:<br>
> > Am I missing something?<br>
> ><br>
> I think the problem I was thinking of is the combination of function<br>
> overloading and keyword arguments - then you have a number of possible<br>
> function signatures that grows exponentially with the number of optional<br>
> arguments.  It's not so bad if it's purely positional arguments since then<br>
> you can just treat a function with n optional arguments as n + 1 overloads<br>
> of the function.<br>
<br>
</span>I'm not sure. You should be able to statically determine which keyword<br>
arguments are passed in a given call, fill the missing ones with nulls<br>
or default values, sort, and generate a call to a single purely<br>
positional underlying implementation.<br>
<span class=""><br>
><br>
> It might take a bit of implementation work to get to work with the other<br>
> function type checking logic in Swift/T, but it seems tractable.  It's<br>
> already a bit complicated trying to work out the input types of the<br>
> function arguments when there's the possibility of type variables, option<br>
> types, etc.<br>
<br>
</span>Shouldn't polymorphism come before fancy type stuff? :)<br>
<span class=""><br>
><br>
> There are some weird corner cases.  For example, which implementation of<br>
> avg would this call?<br>
> avg([]);<br>
<br>
</span>Unless there is some mechanism that can ensure that it doesn't matter,<br>
or a mechanism allowing you to overload based on specific values (like<br>
pattern matching), then you probably have to have a way to say exactly<br>
which function should be called. Java requires you to do an explicit<br>
cast of arguments that would otherwise result in ambiguity.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
<br>
</font></span></blockquote></div><br></div>