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 NAA31601; Mon, 5 May 2003 13:29:14 +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 NAA31857 for ; Mon, 5 May 2003 13:29:13 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h45BTCT01636; Mon, 5 May 2003 13:29:12 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (markus@localhost.ai.univie.ac.at [127.0.0.1]) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.3) with ESMTP id h45BTCwf017271; Mon, 5 May 2003 13:29:12 +0200 Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.3) id h45BTB89017270; Mon, 5 May 2003 13:29:11 +0200 Date: Mon, 5 May 2003 13:29:11 +0200 From: Markus Mottl To: Xavier Leroy Cc: caml-list@inria.fr Subject: Re: [Caml-list] recursive modules Message-ID: <20030505112911.GA15651@fichte.ai.univie.ac.at> Mail-Followup-To: Xavier Leroy , caml-list@inria.fr References: <20030505102121.B23988@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030505102121.B23988@pauillac.inria.fr> User-Agent: Mutt/1.4.1i X-Spam: no; 0.00; caml-list:01 recursion:01 functorize:01 fixpoint:01 pragmatic:01 outweigh:01 ocaml:01 rec:01 checking:01 mottl:02 exception:02 modules:02 module:03 binding:03 wrote:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 05 May 2003, Xavier Leroy wrote: > What this extension provides is a "module rec ... and ..." binding > that allows the definition of mutually-recursive modules within the > same compilation units. This looks very promising indeed! > Recursion between compilation units is a different problem that is > not adressed yet. I believe this shouldn't be such a big problem in practice, because one can always functorize one module and tie the recursive knot elsewhere. > To give a flavor of the extension, one can write for instance [snip Set-example] That's surely one of the major examples, where people really want (and need) recursive modules. > The other point worth mentioning is that the detection of ill-founded > recursive definitions (definitions that have no fixpoint in a > call-by-value evaluation regime) is not completely static and may > cause an "Undefined" exception to be thrown at program initialization > time. Guaranteed at program initialization time? But how about local modules? > Fully static prevention of ill-founded recursion would, in the current > state of our knowledge, either rule out too many valuable uses, > or require major complications in the type system. The proposed > approach is a pragmatic compromise rather than a 100% intellectually > satisfying solution. I personally could live with some dynamic checking of this sort. It's always possible to improve static checking afterwards as long as the language specification allows this in principle. The benefits of recursive modules surely outweigh the drawbacks of some dynamic checking. > No decision has been taken yet concerning the possible integration of > this extension in a future release of OCaml. This is of course a matter of how progressive (aggressive?) you want the main distribution to be. I think that more exotic but otherwise usable features in a distribution won't harm as long as they do not affect normal work. Why not add this as usual to the "language extensions" section of the manual? People who want to be on the safe side are not forced to use anything that's in there. This would make it much easier to get feedback, because only few people are daring enough to test things with some CVS-branch. Regards, Markus Mottl -- Markus Mottl http://www.oefai.at/~markus markus@oefai.at ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners