[Swift-devel] Reconsidering function overloading

[Michael Wilde]

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?

I.e. if we have:

   max( float[ ] )
   max( int[ ] )
   sum( int[ ] )
   reduce(T, T[ ], (T) f ( int[ ] ) )

Then we have to say:

    reduce(0, [1, 10, 3, 4], max( int[ ] ) )

but we could also say:

    reduce(0, [1, 10, 3, 4], sum )

And if we wanted uniformity over convenience we could insist that 
function references must always be passed with type signatures even when 
unambiguous.

Does that approach work consistently and reasonably?

- Mike


On 1/28/15 7:07 AM, Michael Wilde wrote:
>
> I think #1 is reasonable.
>
> I don't think #3 is in practice that bad, though.
>
> Another variation on #3 is:
>
> 6. Ban using function references as arguments/returns in overloaded 
> functions (for now).
>
> Note that Apple's Swift makes heavy use of type inference. It might be 
> useful to see how it handles this issue.
>
> An advantage to #1 is that we could add support for overloading at a 
> later time.
>
> 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.
>
> - Mike
>
> On 1/27/15 9:42 PM, 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
>
> -- 
> Michael Wilde
> Mathematics and Computer Science          Computation Institute
> Argonne National Laboratory               The University of Chicago
>
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-- 
Michael Wilde
Mathematics and Computer Science          Computation Institute
Argonne National Laboratory               The University of Chicago

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150128/6f5f683c/attachment.html>