<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>