English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Lazy modules
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-03-17 (17:43)
From: David Allsopp <dra-news@m...>
Subject: RE: [Caml-list] Lazy modules
Dario Teixeira wrote:
> I've come across a problem which though novel to me, I presume must be
> familiar to those with more ML baggage.  Namely, I need a module whose
> values are not known at the initialisation stage, since they can only be
> determined after reading a configuration file.  If this were a lone
> value, I would declare it as a lazy value which when forced would read
> from the configuration file.  But how can I achieve similar semantics
> with a whole module?

I've hit this similarly with databases - if for example you have a signature DB and modules, say, OracleDB, MSSQLDB, PostgresDB. What I'd wanted in the past is a module DB which is one of those three but determined at runtime when a configuration file is loaded. I couldn't find a satisfactory solution with OCaml 3.09 at the time which didn't involve recompiling on each change.

> I do have a solution which though hackish and relying on a language
> extension (local modules) seems to work: I create the module on demand
> via a functor parameterised over an empty sig:

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. 

> module Socket_maker (S: sig end) : Client.SOCKET = struct
>     let sockaddr = !Config.sockaddr
>     let sockdomain = !Config.sockdomain
>     let socktype = !Config.socktype
>     let sockproto = !Config.sockproto
> end
> let foo =
>     let module Socket = Socket_maker (struct end) in
>     ...
> But I wonder a) what's the penalty associated with the runtime
> application of the functor, and

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. There are I believe some performance overheads in using modules if you care about speed as some optimisations in ocamlopt can't happen across module boundaries. My impression has been that if you're that worried about these slight performance hits then maybe OCaml is the wrong language for you :o)

> b) if there's some better way of doing this.  Any thoughts?

I believe that the module system due for OCaml 3.12.0 will allow this kind of runtime application of functors as modules are first class values.

Hope that's helpful - the inability to do what you're wanting to do is one of the reasons that I've never delved deeply into the module system - powerful as it may be, it didn't seem to be able to help performing a simple task (similar to yours) that I wanted it to do (I have also in the past wanted to exactly what you're doing - i.e. a module of loaded configuration values).