[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