Browse thread
Lazy modules
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-03-18 (11:10) |
From: | David Allsopp <dra-news@m...> |
Subject: | RE: [Caml-list] Lazy modules |
Alain Frisch wrote: > On 3/17/2010 6:42 PM, David Allsopp wrote: > > AFAIK local modules is a syntax extension not a compiler extension - I > > expect (not looked at it) that the syntax extension simply alpha > > renames all the local module declarations to make them unique and puts > > them globally... a very useful extension but no expressive power > > added. > > This is not true. Local modules are not lifted in any way. This is not > simply a syntax extension. For instance, if the local module has > toplevel side-effects (e.g. a structure item like: let () = > print_endline "Hello"), then the side effect will occur every time the > local module is evaluated. I've muddled this with something else! I seem to have muddled a lot in my post... :$ > At runtime, a structure is represented simply by a block with GC tag 0, > exactly as a record or a tuple. The block contains dynamic components of > the structure (values, sub-modules, exceptions, classes) in the order > given by its signature. Evaluating a structure simply evaluates its > runtime components a build the block. > > A functor is represented as a function. > > >The module system at present is a compile time feature (I think that's > >universally true - even with weird things like recursive modules) - > >functors are simply a way of introducing more modules so there is no > >runtime overhead in using a functor. > > Modules and functors are much more dynamic than what you believe. The > introduction of first-class module did not require any change in the way > modules are compiled. > > A local module which is a functor application really applies the functor > at runtime and evaluates the functor body every time the local module > expression is evaluated. Live 'n learn - thanks for the correction! David