From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <David.Teller@univ-orleans.fr>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled 
	version=3.1.3
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id C9DD5BBC1
	for <caml-list@yquem.inria.fr>; Tue, 29 Apr 2008 21:48:44 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtQAABIYF0jCpx6wlmdsb2JhbACRTgEBAQEJBQgYmxU
X-IronPort-AV: E=Sophos;i="4.25,724,1199660400"; 
   d="scan'208";a="12099454"
Received: from smtpmin.univ-orleans.fr (HELO min.univ-orleans.fr) ([194.167.30.176])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 29 Apr 2008 21:48:44 +0200
Received: from smtps.univ-orleans.fr (localhost [127.0.0.1])
	by min.univ-orleans.fr (Postfix) with ESMTP
	id 40A0E12B3D6; Tue, 29 Apr 2008 21:48:44 +0200 (CEST)
Received: from [192.168.0.12] (ras75-4-82-235-58-110.fbx.proxad.net [82.235.58.110])
	by smtps.univ-orleans.fr (Postfix) with ESMTP id 082FD36E5B;
	Tue, 29 Apr 2008 21:48:47 +0200 (CEST)
Subject: RE: [Caml-list] Invoking the standard library ?
From: David Teller <David.Teller@univ-orleans.fr>
To: David Allsopp <dra-news@metastack.com>
Cc: Caml <caml-list@yquem.inria.fr>
In-Reply-To: <003a01c8aa2c$5962f6c0$017ca8c0@countertenor>
References: <1209479205.11285.15.camel@Blefuscu>
	 <003a01c8aa2c$5962f6c0$017ca8c0@countertenor>
Content-Type: text/plain
Date: Tue, 29 Apr 2008 21:50:03 +0200
Message-Id: <1209498604.7286.43.camel@Blefuscu>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; univ-orleans:01 0100,:01 struct:01 endline:01 cmo:01 cmi:01 cmi:01 cmo:01 compilation:01 ocamldep:01 cmx:01 cmx:01 ocamlc:01 stdlib:01 struct:01 

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.