Overload resolution simplification

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Sat Aug 17 08:23:07 PDT 2013


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
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

More information about the lambda-spec-observers mailing list