let f1 = ...
let f2 = ...
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,