Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Christian Boos <boos@arthur.u-strasbg.fr>
To: caml-list@inria.fr
Subject: Dynamic module creation
Date: Wed, 14 May 1997 17:00:32 +0200	[thread overview]
Message-ID: <199705141500.RAA02348@arthur.u-strasbg.fr> (raw)


[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






                 reply	other threads:[~1997-05-14 15:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199705141500.RAA02348@arthur.u-strasbg.fr \
    --to=boos@arthur.u-strasbg.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox