[nem-en] Re: Late Binding in Nemerle
Snaury
snaury at gmail.com
Tue Jul 4 20:17:08 CEST 2006
On 7/4/06, Kamil Skalski <kamil.skalski at gmail.com> wrote:
> Ok, you are right that it is usually better to not apply late in
> questionable situations. But still my intuitions is that if one
> specify 'late' then it should expand to the whole expression.
>
> I'm talking about late expr + expr vs late (expr) + expr vs
> (late expr) + expr
And here we have a gotcha. late expr + expr and late (expr) + expr are
passed to late in the same, indistinguishable form. Only (late expr) +
expr is where we have a difference.
> My intuition is that late has very low precedence (it does not stick
> only to the nearest expression, but to the whole one) and it captures
> 'expr + expr'.
>
> Also, not that usually '(late expr) OP expr' does not make any
> sense, since late always returns object and most operators do not take
> object as parameter.
Nope, because : and :> operators are also passed inside of late, I'm
dealing with them. So you can write: late expr :> int + expr. In late
it is +(:>(expr, int), expr). If I wasn't dealing with plus in a
special way, I won't even know what to do here (+ cannot be late
bound). And if I processed both sides it would be:
late (o.LateBoundMethod() :> int) + int.Parse(Console.ReadLine())
Someone didn't know that both sides were process late bound, which
gave an error. Or even better, imagine on the right side was some
compile time method returning int:
late (o.LateBoundMethod() :> int) + m.MethodReturnsInt()
but when MethodReturnsInt is late bound it returned object. int +
object is wrong, go figure where someone made a mistake. :)
P.S.
Actually, I now have another idea: analyze expressions more deeply and
do late binding only on expressions of type object. But I'm not sure
how complex it will be. x_x
More information about the devel-en
mailing list