Re: Overloaded unification

David B. Benson wrote:
> On Jan 25, 6:31 pm, Jon Harrop <use...@[EMAIL PROTECTED]
> wrote:
>> ... How are type cl***** too restrictive for your needs?
> 
> In SML @[EMAIL PROTECTED]
 has type
> 
> 'a list * 'a list -> 'a list
> 
> Consider
> 
> overload fun @[EMAIL PROTECTED]
(A,i) = Array.sub(A,i)
> 
> so this @[EMAIL PROTECTED]
 has type 'a array * int -> 'a
> but with the infix notation, we can now write
> 
> [A@[EMAIL PROTECTED]
> 
> to provide a (slightly silly) example.
> 
> Don't see how to use type cl***** for this ad-hocery.

I see, yes, of course.

F# has to handle such uncontrolled overloading because other .NET
languages
can (and often do) use it. Statically-resolved overloading basically
completely undermines type inference and leads to many type annotations in
F# (it simply bails at the first ambiguous overload). If you're willing to
be more lenient you might be able to keep more general types around for
longer but I suspect things will get very complicated very quickly for the
user so it will almost certainly be substantially less productive.

You might also like to look at Scala, which inherits similar problems from
the JVM but, IMHO, its solution is strictly worse in this respect because
it sacrifices type inference globally rather than just when overloads are
involved and, thus, loses the essence of ML.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u