<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
One more possibility occurs: could we allow overloaded functions to
pass/return function reference args if we required that when a
function reference arg is overloaded, it must be passed with a
disambiguating type signature?<br>
<br>
I.e. if we have:<br>
<br>
max( float[ ] )<br>
max( int[ ] )<br>
sum( int[ ] )<br>
reduce(T, T[ ], (T) f ( int[ ] ) )<br>
<br>
Then we have to say:<br>
<br>
reduce(0, [1, 10, 3, 4], max( int[ ] ) )<br>
<br>
but we could also say:<br>
<br>
reduce(0, [1, 10, 3, 4], sum )<br>
<br>
And if we wanted uniformity over convenience we could insist that
function references must always be passed with type signatures even
when unambiguous.<br>
<br>
Does that approach work consistently and reasonably?<br>
<br>
- Mike<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/28/15 7:07 AM, Michael Wilde
wrote:<br>
</div>
<blockquote cite="mid:54C8DF25.9030301@anl.gov" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
I think #1 is reasonable.<br>
<br>
I don't think #3 is in practice that bad, though.<br>
<br>
Another variation on #3 is:<br>
<br>
6. Ban using function references as arguments/returns in
overloaded functions (for now).<br>
<br>
Note that Apple's Swift makes heavy use of type inference. It
might be useful to see how it handles this issue.<br>
<br>
An advantage to #1 is that we could add support for overloading at
a later time.<br>
<br>
A point in favor of #3 or #6 is that we've lived without either
feature till now; a few restrictions on the pair of new features
will not be very limiting. I don't think it will lead to many "bad
programmer experiences", although I agree that its a wart from a
language design perspective.<br>
<br>
- Mike<br>
<br>
<div class="moz-cite-prefix">On 1/27/15 9:42 PM, Tim Armstrong
wrote:<br>
</div>
<blockquote
cite="mid:CAC0jiV7OrKKe+_uZVJBW_rU3uSQuWfo7MSZkY6v=siNRHK21Dg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hi All,<br>
</div>
I was just starting to look at implementing the function
overloading support required by the current design of the
standard library. I've just realised some of the
complications and wanted to reassess the current design.<br>
<br>
.As soon as I looked at the changes needed, it was obvious
that it interacts with function references in ways that are
probably undesirable. The issue is that a function name
maps to more than one function, and the compiler needs to be
able to disambiguate wherever it is used: in a variable
context as well as a function call context.<br>
</div>
<div><br>
For example, suppose we wanted to provide a reduce function
with type reduce(T, T[], (T) f (T, T)). It seems reasonable
that we'd want to be able to write:<br>
<br>
</div>
<div>reduce(0, [1, 10, 3, 4], max)<br>
<br>
</div>
<div>But if max is overloaded, then we have to be able to
infer from the type of the first and second arguments which
max was meant.<br>
<br>
</div>
<div>As an aside, there's a further level of difficulty in
resolving things correctly if you consider that overloaded
functions can take overloaded functions as arguments<br>
<br>
</div>
<div>There seems to be a number of ways to get around this
problem:<br>
</div>
<div>1. Don't support overloading at all, save complications
at the expense of longer function names<br>
</div>
<div>2. Don't plan on supporting function references at all<br>
</div>
<div>3. Ban using overloaded functions as first-class
functions, force users to work around it. <br>
</div>
<div>4. Attempt to do some basic type inference to
disambiguate, give up if we can't disambiguate from local
information. (C++ approach, essentially)<br>
</div>
<div>5. Full program-wide type inference (Haskell approach)<br>
</div>
<div><br>
</div>
<div>#2 doesn't fit with overall plans for the project, I
don't think. #3 seems pretty unsatisfying and I think we're
best to avoid bad programmer experiences when we have a
cleanish slate to work from. #5 doesn't seem feasible
without major changes to language and compiler.<br>
This leaves #1 and #4. I think I could make #4 work in
Swift/T, but it would be days of work and getting all the
corner cases may be a challenge - realistically I might just
not get it done. I have no idea how feasible #4 is in
Swift/K. #1 seems like the best effort to reward ratio to
me.<br>
<br>
</div>
<div>Anyway, that was a bunch of detail - does anyone have any
thoughts or opinions? Have I missed anything?<br>
</div>
<div><br>
I'm already assuming that we just shouldn't support
overloading functions with any other kind of polymorphic
arguments - it's not really necessary and too complicated to
implement</div>
<div><br>
</div>
<div>- Tim<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Swift-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Wilde
Mathematics and Computer Science Computation Institute
Argonne National Laboratory The University of Chicago
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Swift-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a>
<a class="moz-txt-link-freetext" href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Wilde
Mathematics and Computer Science Computation Institute
Argonne National Laboratory The University of Chicago
</pre>
</body>
</html>