<div dir="ltr"><div>I think lambdas are a nice orthogonal way to solve it here, but yeah, I don't think they're in the plans in the immediate future.<br><br></div>- Tim<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 2:39 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">Which ultimately isn't much different from having to do:<br>
<br>
(float x) minFloat(float[] a) {<br>
  x = min(a);<br>
}<br>
<br>
reduce(a, minFloat);<br>
<br>
So maybe that isn't much progress.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, 2015-01-28 at 12:23 -0800, Mihael Hategan wrote:<br>
> Here's another idea. If we do support lambda expressions, then:<br>
><br>
> - a direct reference to an overloaded function when no parameter type is<br>
> available should result in an ambiguity error<br>
> - a user can resolve the issue by writing an explicit lambda expression<br>
> which calls the overloaded function, but this time with normal parameter<br>
> type information available<br>
><br>
> E.g:<br>
><br>
> min = reduce(a, min); // error<br>
> min = reduce(a, lambda(float x) { return min(x); });<br>
><br>
> This requires no specialized casting mechanism. Of course, if lambda<br>
> expressions weren't in the plans, this might be more work.<br>
><br>
> Mihael<br>
><br>
> On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote:<br>
> > Hi All,<br>
> >   I was just starting to look at implementing the function overloading<br>
> > support required by the current design of the standard library.  I've just<br>
> > realised some of the complications and wanted to reassess the current<br>
> > design.<br>
> ><br>
> > .As soon as I looked at the changes needed, it was obvious that it<br>
> > interacts with function references in ways that are probably undesirable.<br>
> > The issue is that a function name maps to more than one function, and the<br>
> > compiler needs to be able to disambiguate wherever it is used: in a<br>
> > variable context as well as a function call context.<br>
> ><br>
> > For example, suppose we wanted to provide a reduce function with type<br>
> > reduce(T, T[], (T) f (T, T)).  It seems reasonable that we'd want to be<br>
> > able to write:<br>
> ><br>
> > reduce(0, [1, 10, 3, 4], max)<br>
> ><br>
> > But if max is overloaded, then we have to be able to infer from the type of<br>
> > the first and second arguments which max was meant.<br>
> ><br>
> > As an aside, there's a further level of difficulty in resolving things<br>
> > correctly if you consider that overloaded functions can take overloaded<br>
> > functions as arguments<br>
> ><br>
> > There seems to be a number of ways to get around this problem:<br>
> > 1. Don't support overloading at all, save complications at the expense of<br>
> > longer function names<br>
> > 2. Don't plan on supporting function references at all<br>
> > 3. Ban using overloaded functions as first-class functions, force users to<br>
> > work around it.<br>
> > 4. Attempt to do some basic type inference to disambiguate, give up if we<br>
> > can't disambiguate from local information. (C++ approach, essentially)<br>
> > 5. Full program-wide type inference (Haskell approach)<br>
> ><br>
> > #2 doesn't fit with overall plans for the project, I don't think. #3 seems<br>
> > pretty unsatisfying and I think we're best to avoid bad programmer<br>
> > experiences when we have a cleanish slate to work from.   #5 doesn't seem<br>
> > 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<br>
> > would be days of work and getting all the corner cases may be a challenge -<br>
> > realistically I might just not get it done.  I have no idea how feasible #4<br>
> > is in Swift/K. #1 seems like the best effort to reward ratio to me.<br>
> ><br>
> > Anyway, that was a bunch of detail - does anyone have any thoughts or<br>
> > opinions?  Have I missed anything?<br>
> ><br>
> > I'm already assuming that we just shouldn't support overloading functions<br>
> > with any other kind of polymorphic arguments - it's not really necessary<br>
> > and too complicated to implement<br>
> ><br>
> > - Tim<br>
> > _______________________________________________<br>
> > Swift-devel mailing list<br>
> > <a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
> > <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> Swift-devel mailing list<br>
> <a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
> <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>