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 SAA10449; Mon, 5 May 2003 18:59:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA03871 for ; Mon, 5 May 2003 18:59:55 +0200 (MET DST) Received: from grace.speakeasy.org (grace.speakeasy.org [216.254.0.2]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h45GxsH18451 for ; Mon, 5 May 2003 18:59:54 +0200 (MET DST) Received: (qmail 32018 invoked by uid 36130); 5 May 2003 16:59:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 May 2003 16:59:53 -0000 Date: Mon, 5 May 2003 09:59:52 -0700 (PDT) From: brogoff@speakeasy.net To: Xavier Leroy cc: "caml-list@inria.fr" Subject: Re: [Caml-list] recursive modules In-Reply-To: <20030505102121.B23988@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam: no; 0.00; brogoff:01 caml-list:01 fixpoint:01 recursion:01 pragmatic:01 verbosity:01 okasaki's:01 bootstrap:01 elem:01 struct:01 textually:01 nonrecursive:01 compiler:01 speakeasy:01 workaround:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 5 May 2003, Xavier Leroy wrote: > 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. 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. It seems like an acceptable compromise. I've only read the note, and I surely won't get it until I play with the compiler. One thing that I notice is that the scope rule restriction on with type constraints, which adds extra verbosity when trying to work around the restriction on module constraints, also adds sone extra verbosity to your version of Okasaki's bootstrap heaps. It would be nicer to write module rec BE : ORDERED with type t = E | H Elem.t * PrimH.heap = struct ... etc., etc., ... in the same way that it would be nicer to not have to textually copy signatures in the workaround. Could that be fixed easily? It looks like it could be fixed in the current (nonrecursive) module system pretty easily but I don't know about your proposal. Nice work! This problem is a real pain, and your proposal provides a real fix. -- Brian ------------------- 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