Version française
Home     About     Download     Resources     Contact us    
Browse thread
Dynamic module creation
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christian Boos <boos@a...>
Subject: Dynamic module creation

[english version only, sorry !]


	Hello,

  I would advocate for dynamic creation of structures,
either by building structs 'on the fly' or by dynamic functor application.
These debate was started by A. Conway last year (see
 http://pauillac.inria.fr/caml/caml-list/0425.html), and was concluded
by X. Leroy saying that it could be done, but that it was left out of the
langage for the sake of simplicity.

  I face now the same kind of problem as Mr. Conway, that is, I have a functor
that uses some values from its argument module which are constant in the scope
of the generated module. For different values, I have to apply the functor on
different modules. The problem arises when those value can't be computed at
compile time. Dynamic module creation and functor application could solve this
problem without the need of tricks. Actually, even using refs on values is not
always sufficient when you simultaneously need differents sets of parameters.
And when you come to give explicitly to your functions a record
filled of parameters and functions ... then you're back to Caml-Light hand-made
functors !

X. Leroy said that SML/NJ had this feature, but I couldn't find anything
about that in my sml documentation (by the way, is there a REAL documentation
for SML/NJ, the langage part, not its standard library ?).

My suggestion would be to extend the syntax of expression:

| expr:
|   ...
|   | LOCAL restricted-definition IN expr
|
| restricted-definition:
|  |  module module-name {( module-name : module-type )} [: module-type]
|       = module-expr
|  |  open module-path


The semantic of this extension would be that the expression is
evaluated in a locally-defined environment.

I am aware that one technical difficulty is that this will involve mutual 
recursion between the module and the expression part of the langage, 
both in typing and code generation. 
In the current implementation, the module part is built upon
the expr part.

I think this extension would be really usefull & powerfull.
Any comments ?


-- Christian