Overload resolution simplification

[Ali Ebrahimi]

Hi,

On Sat, Aug 17, 2013 at 6:05 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> This is not really a technical problem. There's no problem to tell
> javac to perform complex inference; the question is, can humans do the
> same?
>
> For anyone accustomed to static typing, `x->expr(x)` is completely
> meaningless - the type of x is unknown, thus the meaning of expr(x) is
> unintelligible (we don't do duck typing).
>
> Therefore the type of `x` must be inferred from the context. That
> process must be very simple and crystal clear such that humans can do
> the same inference with very little effort and with great accuracy.
>
> If the context is assignment or casting, it's crystal clear.
>
> Not so much if the context is method invocation:
>
>     m( x->expr(x) )
>
My proposed Scheme rejects this case. since you can not infer x's type.

>
> if `m` is overloaded, and each version gives a different type to `x`,
>
This case is less than 0.01% and often (99.99%) compiler would infer same
type for x.

> it'll be a great burden for humans to mentally try out each version
> and see which makes sense. If javac accepts that code, as a reader
> I'll be very uncomfortable because it's too much work for my tiny
> brain to parse that code.
>
If we have accurate rules and train peoples perfectly they can do that as I
did.
In other hand, this is where IDEs can play their roles. even without
overloading you require IDE's help.

>
> If we require that `m` must not be overloaded, it'll cut down a lot of
> work, not only for javac, but mainly for human brains. If I see that
> code, given that it compiles, I know instantly that `m` is not
> overloaded, and the type of the lambda expression is the corresponding
> method parameter.
>
> What if `m` is overloaded, and each version gives the same type to
> `x`? Javac used to accept it; now it does not. I disagree with that
> change.
>
> With the previous javac, when I see code `m( x->expr(x) )`, given that
> it compiles, I  only need to check one version of `m` to figure out
> the type of `x`, I know that all other versions of `m` must agree on
> that type. Whether `m` is overloaded or not does not really matter to
> me in this process. So it does not increase my workload to parse the
> lambda expression if `m` is overloaded. (It does increase the workload
> of javac to verify that all versions of `m` agree on the type of `x`)
>
specializing rules increase complexity.

>
> There's another problem though, if `expr(x)` itself is a lambda
> expression. If `m` is overloaded, I'll say that the shape of `expr(x)`
> must be self evident (given the type of `x`) otherwise the code should
> be rejected.
>
I agree.

Ali ebrahimi