hg: lambda/lambda/langtools: Next round of implementation reflecting the latest 'State of the Lambda' draft; implemented features are:

[Neal Gafter]

On Monday, July 26, 2010, Nathan Bryant <nathan.bryant at linkshare.com> wrote:
> As an end user, I might expect the compiler do the following--in
> informal terms:
>
> 1) In the presence of overloaded methods, reduce the set of possible
> overloads by trying all possibilities and eliminating those that can't
> possibly compile.
> 2) Among the remaining candidates, choose the most specific according to
> the usual rules.
> 3) If there is no "most specific" overload, e.g. because some subset S
> of the possible target types have a lub() that is not a member of S,
> then it is a compile time error that requires disambiguation by the
> programmer.
>
> This seems simple to implement, simple to specify in formal terms, easy
> enough to explain to Remi's students ;), and fairly likely to avoid
> surprise, at least in the sense that we stop at step 3 and don't try to
> play any further guessing games.
>
> On the other hand, I worry step 1; in the event that the programmer
> inadvertently wrote something that couldn't match the intended target,
> it could be a source of surprise to eliminate candidates that couldn't
> possibly compile.
>
> Neal, do you have any better ideas? ;)

The problem here is the "can't possibly compile", which in the current
specification (in general) requires binding the entire lambda body for
each possible overloading.  For nested or chained invocations, this
can be quite complex.  I prefer that we define a subtype relation
between lambda expressions and object types (SAM types and function
types) and use that for overload resolution as usual.  That is the
approach that BGGA takes.

Trial binding should only be necessary for parameter type inference.