<div dir="ltr"><div><div><div>I'm still not sure what you'd do with situationally ambiguous functions though.<br><br></div>E.g. with the following<br>f(float x=0.0, int y=0)<br>f(int y=0)<br><br>Neither dominates the other, since f(0.0, 0) and f(0) would get dispatched to the first and second.  So it's not like it's obviously wrong code that should be an automatic compile error.  I'm not sure if there is an algorithm in general to detect partially ambiguous functions (depending on details of the type system).  If there was you could try to warn or error on partially ambiguous functions, although providing comprehensible explanations of the problem might be an issue. <br><br></div>I think supporting overloading only for specific built-ins isn't such a bad thing (we do that for arithmetic operators, for example).  I think some users might find it preferable to define overloads f(int) and f(float), but they can achieve the same effect with fInt(int) and fFloat(float), even if it's less aesthetically pleasing.<br><br>You could say the same for my type variable thing I guess too - just special case it in the compiler for size() and contains().  Then there would be a limited number of special additional functions like map(), reduce(), etc, that could be special-cased.  But there's no way then that you can achieve the same effect with a finite number of function definitions - you'd have to have an overload for every possible type, or just special-case it in the compiler.<br></div><span class="im"></span><div><div><div><div><div><br>Java sort of gives up on typechecking in that case and just calls .equals(Object).  They didn't really have much of a choice since that was baked in before they had generics.  It's at least simple enough but it's definitely made it easier for bugs to go uncaught in STC, for example - I think there have been at least 15-20 things that I've had to track down that have boiled down to equals being called on two types that aren't comparable.<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 11, 2015 at 11:19 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Sun, 2015-01-11 at 21:48 -0600, Tim Armstrong wrote:<br>
> You can use a positional implementation for sure as long as the caller<br>
> knows the argument names of the function it's calling at compile time.<br>
> You can't reduce it to the problem of resolving overloads for functions<br>
> with purely positional arguments though, since that would require there<br>
> being a single consistent mapping of <argument name> -> <argument position><br>
> across all of the overloaded ones.<br>
<br>
</span>I see what you are saying. I didn't think that far.<br>
<span class=""><br>
><br>
>  You could have it try all of the overloads individually and see which ones<br>
> matched, but by that point I think it's too complicated to be worth it.<br>
<br>
</span>Matching seems reasonable though. You have to do the matching anyway as<br>
part of type checking.<br>
<span class=""><br>
><br>
> It would also have the downside that it's harder to work out if two<br>
> overloads are potentially ambiguous at the function declaration site (it's<br>
> not too bad at the call site - if you have more than one match, it's<br>
> ambiguous).  E.g. if I defined  f(float x=0.0, int y=0) and someone writes<br>
> code with a call to f(y=0);  Now, if I added another overload f(int y=0),<br>
> presumably the compiler wouldn't detect the overloads as ambiguous, since<br>
> most ways of calling either are not, but then the call f(y=0) would break,<br>
> since it's now ambiguous.  Not great for modularity.<br>
<br>
</span>There is the potential of ambiguous calls if the positional types are<br>
identical and there is an overlap between keyword args. In your case<br>
both lack positionals and both have an int y. That assuming no<br>
subtyping. The overlap part is slightly more difficult than the direct<br>
match. But it can reasonably be detected with defined functions.<br>
<span class=""><br>
><br>
> I guess this got into a pretty academic discussion, but I do feel like<br>
> keyword arguments and overloading don't play nicely together, and I do<br>
> remember someone requesting keyword arguments at one point.<br>
><br>
<br>
</span>I think there's an enhancement request in bugzilla for overloading. I<br>
don't know..., I mean yeah, this is pretty academic, but the question<br>
about whether we will support overloading needs to be answered if we are<br>
to come up with a decent common standard library that won't be a moving<br>
target. Well, it's a matter of consistency in K, since run-time<br>
overloading in library functions is supported.<br>
<span class=""><br>
><br>
> With polymorphism, what do you mean by polymorphism though?<br>
<br>
</span>Right there I meant just function overloading. Sorry.<br>
<span class=""><br>
>   I'd think of<br>
> option types and type variables as one form of polymorphism among many, and<br>
> 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,<br>
> array_element), then the type really should require that the arguments have<br>
> types T[] and T.  The alternatives were to either special-case it in the<br>
> compile (not supporting it for user-defined functions and forcing compiler<br>
> changes for every addition operator), or by just giving on typechecking and<br>
> letting the caller pass in anything as long as the first argument is an<br>
> array.<br>
><br>
> The first would have been workable, but a bit limiting, and the second<br>
> would have opened up a can of worms, since then it's possible to compare<br>
> variables of completely different types and you have to work out what the<br>
> equality rules are.  E.g., what does contains([1.0, 2.0], 1) do?<br>
<br>
</span>That still compiles in Java actually, even with generics. But then Java<br>
nailed the equality rules part fairly well.<br>
<br>
[...]<br>
<span class=""><font color="#888888"><br>
Mihael<br>
<br>
</font></span></blockquote></div><br></div></div></div></div></div></div></div>