From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id DAA23817; Tue, 1 May 2001 03:31:12 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA24031 for ; Tue, 1 May 2001 03:31:11 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f411V9X12374 for ; Tue, 1 May 2001 03:31:10 +0200 (MET DST) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id KAA12951; Tue, 1 May 2001 10:31:00 +0900 (JST) To: bpr@best.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] two unrelated questions In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010501103100X.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 01 May 2001 10:31:00 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Brian Rogoff > I think the real beauty of this local module feature is that it allows > things like a local open, which may make open more palatable to > open-phobes. > > though I take it that these kinds of tricks weren't the original goal of > the feature. Still, the syntax is light so these are very painless > workarounds even without the P4 prettification. Indeed, I think they were not the original goal. As I heard it from Xavier, this was mostly intended to allow local instances of functors. Particularly, local exception definitions are one of the rare features present in SML and absent in Caml, and that some SML developpers think that Caml is right about :-) That is, defining local exceptions (and local types also) is a very fine way to shoot oneself in the foot. You end up having plenty of exceptions (or types) with the same name (impossible to distinguish at toplevel), but incompatible. For types, this is still ok since the type checker does not allow it to escape its scope; which can give you funny errors: # let module M = struct type t = A | B end in M.A;; This `let module' expression has type M.t In this type, the locally bound module name M escapes its scope For exceptions, logically a locally defined exception escaping its scope should be a fatal error, but this is not the case (cannot be really enforced). So you can end up at toplevel getting an exception of an unknown name, impossible to catch. (This is the problem SMLers cite most often). On the other hand, I perfectly agree with you that opening a module locally is something you want to do often, and causes no safety problem at all. That's one of the reasons I think mixing it with let module is not good: the let module feature is theoretically subtle, and should be used with care, while a let open construct does nothing (just changes the static scope), and does not require the same caution. Cheers, Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr