From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 4B700BBC1 for ; Tue, 29 Apr 2008 20:20:08 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAAACcEF0iAArkpjWdsb2JhbACBU497AQEBAQkFBgcTmwg X-IronPort-AV: E=Sophos;i="4.25,723,1199660400"; d="scan'208";a="25666674" Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Apr 2008 20:20:00 +0200 Received: from stratocaster.home (c-71-199-104-241.hsd1.pa.comcast.net [71.199.104.241]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m3TIJwbP029684 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 29 Apr 2008 14:19:59 -0400 (EDT) Received: from ecc by stratocaster.home with local (Exim 4.69) (envelope-from ) id 1JquQo-00056J-Qr for caml-list@yquem.inria.fr; Tue, 29 Apr 2008 14:19:58 -0400 Date: Tue, 29 Apr 2008 14:19:58 -0400 From: Eric Cooper To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Invoking the standard library ? Message-ID: <20080429181958.GB18818@stratocaster.home> Mail-Followup-To: caml-list@yquem.inria.fr References: <1209479205.11285.15.camel@Blefuscu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1209479205.11285.15.camel@Blefuscu> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Spam: no; 0.00; 0200,:01 bindings:01 toplevel:01 struct:01 compiler:01 struct:01 bug:01 unbound:01 wrote:01 compile:01 caml-list:01 modules:02 compiling:02 compiling:02 string:02 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