Invoking the standard library ?

Invoking the standard library ?

[David Teller]

   Dear list,

 I'm currently working in a ExtLib-style context in which I'm extending
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. So,
in string.ml, I'd like to be able to write something along the lines of

 include Inria.String

to access the contents of the usual String. Now, at the moment, to do
that, I need to first create my own module Inria (which imports all the
modules of the standard distribution), which then lets me proceed with
this manipulation. Unfortunately, that's a bit clumsy, not to mention
that I haven't found a nice way to get this all to build in one go with
ocamlbuild.

I'd like to know if there's a better mechanism.

Thanks in advance,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] Invoking the standard library ?

[Eric Cooper]

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?

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] Invoking the standard library ?

[Jacques Garrigue]

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

Re: [Caml-list] Invoking the standard library ?

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

Jacques Garrigue a écrit :
> 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:
>>

A very simple solution (that I use for PML) would be to change ocaml
so that a directory in the path is considered as a module whose fields are
the modules and directory inside it ... This allows two files to have the same name
and depending if you open or not the module/directory containing an extended string library,
you can access by open String the original or the extended module.

You can even decide that it is possible to assign a .mli file to a directory to hide some
modules inside it ...

Christophe
-- 
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] Invoking the standard library ?

[Eric Cooper]

On Wed, Apr 30, 2008 at 09:51:00AM +0200, Christophe Raffalli wrote:
> A very simple solution (that I use for PML) would be to change ocaml
> so that a directory in the path is considered as a module whose
> fields are the modules and directory inside it ... This allows two
> files to have the same name and depending if you open or not the
> module/directory containing an extended string library, you can
> access by open String the original or the extended module.

I like this approach -- very elegant.

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] Invoking the standard library ?

[Gordon Henriksen]

On Apr 30, 2008, at 09:38, Eric Cooper wrote:

> On Wed, Apr 30, 2008 at 09:51:00AM +0200, Christophe Raffalli wrote:
>> A very simple solution (that I use for PML) would be to change ocaml
>> so that a directory in the path is considered as a module whose
>> fields are the modules and directory inside it ... This allows two
>> files to have the same name and depending if you open or not the
>> module/directory containing an extended string library, you can
>> access by open String the original or the extended module.
>
> I like this approach -- very elegant.


Note that ocamlopt uses the module name as an entry point and  
including multiple modules with the same name will cause linkage  
conflicts.

— Gordon

Re: [Caml-list] Invoking the standard library ?

[David Teller]

On Wed, 2008-04-30 at 09:05 +0900, Jacques Garrigue wrote:
> 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.

Yeah, that's what I'm realising at the moment. Even with my
Inrialib.List, I end up with "inconsistent assumptions".

> 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.

Would that change the final binary ?

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

RE: [Caml-list] Invoking the standard library ?

[David Teller]

On Tue, 2008-04-29 at 20:07 +0100, David Allsopp wrote:
> I don't quite following the motivation for needing module Inria: there's no
> problem with writing:
> 
> module String = struct
>   include String
>   (* Your functions here *)
> end

Doesn't work whenever the module is contained in its own file.

(*File string.ml*)
include String
let _ = print_endline "Done"
(*end of file string.ml*)

$ ocamlbuild string.cmo
Circular build detected
  (string.cmi already seen in [ string.cmi; string.cmo ])
Compilation unsuccessful after building 1 target (0 cached) in 00:00:00.

$ ocamldep string.ml
string.cmo: string.cmo 
string.cmx: string.cmx 

$ ocamlc string.ml
File "string.ml", line 1, characters 8-14:
Unbound module String

etc.

> but I think perhaps I've not understood the problem properly. That said, why
> is defining module Inria clumsy? I copied the table of contents from the
> StdLib page and with a couple of %s instructions got
> 
> module Inria =
> struct
>   module Arg = Arg
>   module Array = Array
> (* 34 additional lines *)
>   module StringLabels = StringLabels
>   module Sys = Sys
> end
> 
> Which is exactly what you want, right? 

Auto-generating the module is not hard. It's getting everything to
compile without having to hand-write a Makefile (e.g. with ocamlbuild).
Indeed, module Inria depends on [the original] String, [the original]
Sys, etc... and I wouldn't want ocamlbuild or ocamldep to decide
compiling string.ml before inria.ml.


Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

Re: [Caml-list] Invoking the standard library ?

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 3073 bytes --]

After various attempts at this problem a couple months ago, I settled for
the following (not ideal) solution. I suffix all modules I am extending with
a 2. Then I package them up in a module named Lib2, which is defined such
that doing "open Lib2" serves as a drop-in replacement for the Standard
Library. As follows:
---- File lib2.ml ----
module String = String2
module List = List2
include Pervasives2 (* note Pervasives2 is "included" *)

---- File string2.ml ----
include String
let f1 = ...
let f2 = ...

---- File list2.ml ----
include List
let f1 = ...
let f2 = ...

---- File pervasives2.ml ----
include Pervasives
let identity x = x
let (<<-) f g x = f (g x)
let (->>) f g x = g (f x)
...

This solution has at least the following flaws:
- one has to write "open Lib2" in every other file
- the module names String2, List2, etc. are visible but we really don't want
them


On Tue, Apr 29, 2008 at 3:50 PM, David Teller <David.Teller@univ-orleans.fr>
wrote:

> On Tue, 2008-04-29 at 20:07 +0100, David Allsopp wrote:
> > I don't quite following the motivation for needing module Inria: there's
> no
> > problem with writing:
> >
> > module String = struct
> >   include String
> >   (* Your functions here *)
> > end
>
> Doesn't work whenever the module is contained in its own file.
>
> (*File string.ml*)
> include String
> let _ = print_endline "Done"
> (*end of file string.ml*)
>
> $ ocamlbuild string.cmo
> Circular build detected
>  (string.cmi already seen in [ string.cmi; string.cmo ])
> Compilation unsuccessful after building 1 target (0 cached) in 00:00:00.
>
> $ ocamldep string.ml
> string.cmo: string.cmo
> string.cmx: string.cmx
>
> $ ocamlc string.ml
> File "string.ml", line 1, characters 8-14:
> Unbound module String
>
> etc.
>
> > but I think perhaps I've not understood the problem properly. That said,
> why
> > is defining module Inria clumsy? I copied the table of contents from the
> > StdLib page and with a couple of %s instructions got
> >
> > module Inria =
> > struct
> >   module Arg = Arg
> >   module Array = Array
> > (* 34 additional lines *)
> >   module StringLabels = StringLabels
> >   module Sys = Sys
> > end
> >
> > Which is exactly what you want, right?
>
> Auto-generating the module is not hard. It's getting everything to
> compile without having to hand-write a Makefile (e.g. with ocamlbuild).
> Indeed, module Inria depends on [the original] String, [the original]
> Sys, etc... and I wouldn't want ocamlbuild or ocamldep to decide
> compiling string.ml before inria.ml.
>
>
> Cheers,
>  David
>
> --
> David Teller
>  Security of Distributed Systems
>  http://www.univ-orleans.fr/lifo/Members/David.Teller
>  Angry researcher: French Universities need reforms, but the LRU act
> brings liquidations.
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 4782 bytes --]