[Swift-devel] Reconsidering function overloading

[Mihael Hategan]

I personally didn't think that we would implement them (fn pointers and
lambdas) separately. That was based on them being morally connected, but
they are quite different in terms of implementation.

My problem with my solution is that, while min(x, y) will remain nice,
any use of min as a function pointer will actually require what is
equivalent to having minFloat/minInt. whether by lambdas or by actually
writing a minFloat/minInt.

I think this has to be the cost. As before with overloading/keyword
args, the language gains both abilities in general, with none of the
corner case affecting anything that could have been done before cleanly.
We could maybe improve things later by adding a terse casting operator.

I don't think type inference (#5) will be simple if we support
universally quantified types.

f(T[] a, (T[] -> T) g) {
  g(a);
}

f(a, min)

You would basically end up with a constraint system similar to SML's.
It's doable, but there are lots of moving parts.

So I think ultimately #3 might be the reasonable choice.

I would also add #6, which would be to do dynamic dispatch in cases
where full static resolution fails. It probably comes with a can of
worms if its own.

Mihael


On Wed, 2015-01-28 at 16:24 -0600, Tim Armstrong wrote:
> 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.
> 
> - Tim
> 
> On Wed, Jan 28, 2015 at 2:39 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:
> 
> > Which ultimately isn't much different from having to do:
> >
> > (float x) minFloat(float[] a) {
> >   x = min(a);
> > }
> >
> > reduce(a, minFloat);
> >
> > So maybe that isn't much progress.
> >
> > Mihael
> >
> > On Wed, 2015-01-28 at 12:23 -0800, Mihael Hategan wrote:
> > > Here's another idea. If we do support lambda expressions, then:
> > >
> > > - a direct reference to an overloaded function when no parameter type is
> > > available should result in an ambiguity error
> > > - a user can resolve the issue by writing an explicit lambda expression
> > > which calls the overloaded function, but this time with normal parameter
> > > type information available
> > >
> > > E.g:
> > >
> > > min = reduce(a, min); // error
> > > min = reduce(a, lambda(float x) { return min(x); });
> > >
> > > This requires no specialized casting mechanism. Of course, if lambda
> > > expressions weren't in the plans, this might be more work.
> > >
> > > Mihael
> > >
> > > On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote:
> > > > Hi All,
> > > >   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.
> > > >
> > > > .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.
> > > >
> > > > 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:
> > > >
> > > > reduce(0, [1, 10, 3, 4], max)
> > > >
> > > > 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.
> > > >
> > > > 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
> > > >
> > > > There seems to be a number of ways to get around this problem:
> > > > 1. Don't support overloading at all, save complications at the expense
> > of
> > > > longer function names
> > > > 2. Don't plan on supporting function references at all
> > > > 3. Ban using overloaded functions as first-class functions, force
> > users to
> > > > work around it.
> > > > 4. Attempt to do some basic type inference to disambiguate, give up if
> > we
> > > > can't disambiguate from local information. (C++ approach, essentially)
> > > > 5. Full program-wide type inference (Haskell approach)
> > > >
> > > > #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.
> > > > 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.
> > > >
> > > > Anyway, that was a bunch of detail - does anyone have any thoughts or
> > > > opinions?  Have I missed anything?
> > > >
> > > > 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
> > > >
> > > > - Tim
> > > > _______________________________________________
> > > > Swift-devel mailing list
> > > > Swift-devel at ci.uchicago.edu
> > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> > >
> > >
> > > _______________________________________________
> > > Swift-devel mailing list
> > > Swift-devel at ci.uchicago.edu
> > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> >
> >
> >