caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: ecc@cmu.edu
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Invoking the standard library ?
Date: Wed, 30 Apr 2008 09:05:41 +0900 (JST)	[thread overview]
Message-ID: <20080430.090541.77051652.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <20080429181958.GB18818@stratocaster.home>

From: Eric Cooper <ecc@cmu.edu>
Subject: Re: [Caml-list] Invoking the standard library ?
Date: Tue, 29 Apr 2008 14:19:58 -0400

> On Tue, Apr 29, 2008 at 04:26:45PM +0200, David Teller wrote:
> > modules String, Stream, etc. For this, I need to include the original
> > module, as provided in the standard library, and add stuff. Now, the
> > trick is that I'd like to keep the same name as the original module.
> 
> My first thought was that the usual shadowing of bindings could
> be used, and indeed the following works fine in the toplevel:
> 
> module String =
>   struct
>     include String
>     let my_extension = ...
>   end
> 
> But when I tried to compile it separately (just
>     include String
>     let my_extension = ...
> in a file "string.ml"), I got an error "Unbound module String".
> 
> I don't understand why the behavior is different in these two cases;
> apparently the batch compiler binds String as soon as it starts compiling
> "string.ml", whereas the top-level does so only after compiling the
> struct body.  Is this a bug?

This is a limitation of ocaml's mapping between file names and
modules: a program cannot contain two files with the same name.
Even if you somehow succeed in doing so by tricking the compiler,
you're on your way for lots of trouble.

So the answer is that the new string module should be in a file with a
different name. This is actually what is done in the distribution for
labelled versions of standard library modules: they are first defined
with different names (ListLabels, ...), and then wrapper modules are
defined containing them with standard names (StdLabels). Of course
once you've done "open StdLabels" there is no way to access the
original List module (except if you've first defined an alias for it
with a different name).

It has been discussed at times that putting the standard library in a
packed module would alleviate this problem. However, this would make
it monolithic, meaning that all programs would have to include all the
standard library.

Regards,

Jacques Garrigue


  reply	other threads:[~2008-04-30  0:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 14:26 David Teller
2008-04-29 18:19 ` [Caml-list] " Eric Cooper
2008-04-30  0:05   ` Jacques Garrigue [this message]
2008-04-30  7:51     ` Christophe Raffalli
2008-04-30 13:38       ` Eric Cooper
2008-05-01  1:59         ` Gordon Henriksen
2008-04-30 11:35     ` David Teller
     [not found] ` <003a01c8aa2c$5962f6c0$017ca8c0@countertenor>
2008-04-29 19:50   ` David Teller
2008-04-29 22:58     ` Ashish Agarwal

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=20080430.090541.77051652.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@yquem.inria.fr \
    --cc=ecc@cmu.edu \
    /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;
as well as URLs for NNTP newsgroup(s).