From: Mark Hayden <hayden@cs.cornell.edu>
To: caml-list@pauillac.inria.fr
Subject: Re: Merging Modules
Date: Thu, 12 Sep 1996 09:16:01 -0400 [thread overview]
Message-ID: <199609121316.JAA01731@verdandi.cs.cornell.edu> (raw)
In-Reply-To: Your message of "Thu, 12 Sep 1996 11:54:10 +0200." <199609120954.LAA18065@pauillac.inria.fr>
>The Caml language does not support this. In Objective Caml, you can
>have several sub-modules in one input file, but still all the source
>code for the top module must reside in one source file.
I would find it useful if the name of the top module in the source file was
not determined by the file name. It would be nice if by default O'caml
used the file name as the name for a module, but allowed you to override
that with a different name. (This introduces problems because the
interface searching assumes the module name is the same as the .cmi file
name, but there are ways to get around this.)
Here is an example where this would be useful. I have a module x.mli for
which I've built several different implementations: x1.ml, x2.ml, x3.ml.
In order to compile each implementation with the module name X, I have to
(1) copy the module xi.ml to x.ml, (2) compile x.ml to x.cmo, and (3) copy
x.cmo to xi.cmo.
>A possibility is to compile each file as a distinct module (M1, M2, ...),
>then have one extra file/module M that re-exports what is made public
>to the remainder of the program, which then refers only to M. This is
>exemplified in the Caml Light user's manual, chapter on camllibr.
It would also be useful to allow several top level modules to reside in one
implementation file.... I'm thinking of cases where a lot of tiny modules
have to reside in separate files in order to use the O'caml module system.
Sometimes one would prefer to have the modules all in the same
implementation file (for instance, to improve compilation speed).
>Another possibility is to generate the module implementation from
>several input files in your Makefile, using "cat", "cpp", or whatever
>external tool does the job.
>
>Regards,
>
>- Xavier Leroy
Wouldn't it be better if O'caml included some mechanisms so that these
kinds of limitations didn't require hacks with cpp or cat to get around
them? I think O'caml is great as it is now, but a few additions to prevent
these problems would significantly improve it.
--Mark Hayden
prev parent reply other threads:[~1996-09-12 15:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-09-06 9:35 Vyskocil Vladimir
1996-09-12 9:54 ` Xavier Leroy
1996-09-12 13:16 ` Mark Hayden [this message]
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=199609121316.JAA01731@verdandi.cs.cornell.edu \
--to=hayden@cs.cornell.edu \
--cc=caml-list@pauillac.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