[nem-en] Re: Late Binding in Nemerle

Snaury snaury at gmail.com
Tue Jul 4 19:33:49 CEST 2006


On 7/4/06, Kamil Skalski <kamil.skalski at gmail.com> wrote:
> > //       def num = late s.Length :> int + 13 // now works correctly!
> So the whole expression  's.Length :> int + 13' is late bound? I guess
> this should be the behaviour - make the whole expression late.

Actually not. What I'm thinking is making <ugh, I forgot the word for
this: means weight/precedence of operator> as little as possible. So
in late s.Length :> int only s.Length is late-expr.

> > //         somevar.someprop = o.Property // careful! somevar became late bound, o did not!
> Is it a fixed bug or the current behaviour? I guess ALL expressions
> inside late { } should be late bound.

Are you sure if this is what is wanted? I am not, because if
everything is late bound, then certain things would become impossible
to do. And I'm not sure whether I can delay my macro until the moment
when I can get more type info. Currently I do all macro expansion
right away. Anyway, I'll just quote formal syntax from changelog from
latest sources (slightly modified to reflect latest changes):

     late late-expr
     late {
       late-expr;
       late-expr;
       ...
     }

     late-expr is analyzed in two passes (on two levels):
       1) Outer Level (where normal expressions are separated from
late expressions)
          def expr = late-expr
          mutable expr = late-expr
          _ = late-expr
          name = late-expr
          late-expr <op> expr...
          none of the above -> late-expr is passed to inner level
       2) Inner Level (where late binding expressions are analyzed)
          late-expr = expr
          late-expr . name (args...)
          late-expr . name [args...]
          late-expr . name
          late-expr . [args...]
          late-expr [args...]
          none of the above -> late-expr is treated as expr

> > //         Console.WriteLine(...) // console is not an object, so you
> > can't do this :)
> You might consider checking if "Console" is a visible type, for
> example by using Macros.IsTypeName, just like Arthur did. I'm not sure
> what you should do in case it actually is a type... make it a
> latebound call to static method?

Making latebound call to static method doesn't make sense if we
already know the type. :) However, if chacking if Console is type or
not is really that easy, I'll see...



More information about the devel-en mailing list