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 BAA13343; Mon, 28 May 2001 01:13:13 +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 BAA06289 for ; Mon, 28 May 2001 01:13:11 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f4RND8r26878 for ; Mon, 28 May 2001 01:13:08 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id BAA24779; Mon, 28 May 2001 01:13:02 +0200 (MET DST) Date: Mon, 28 May 2001 01:13:02 +0200 From: Markus Mottl To: Brian Rogoff Cc: Tom _ , caml-list@inria.fr Subject: Re: [Caml-list] classes vs modules Message-ID: <20010528011302.A24955@miss.wu-wien.ac.at> References: <20010527181431.A5444@miss.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bpr@best.com on Sun, May 27, 2001 at 13:54:21 -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 27 May 2001, Brian Rogoff wrote: > On Sun, 27 May 2001, Markus Mottl wrote: > > Out of curiousity, would it be unsound to allow functions like the > > following: > > > > let f (cmp : 'a -> 'a -> bool) = > > let module SomeSet = > > Set.Make (struct type t = 'a let compare = cmp end) in > > () > > You can do this now if you make a PolySet module by copying the > "monomorphic" implementation from the stdlib, changing elt and t to > 'a elt and 'a t and, using that instead of Set, something like: One could certainly do this. Still, I am not sure whether this issue isn't slightly different here: 'a has to be bound, of course, and parameterized types let you create such bindings, making them explicit across interfaces. If the binding didn't exist, you could accidently mix sets with incompatible elements. Here, however, the type variable is indeed bound, and there is no way that we can escape this binding (if I am not mistaken): if you happen to use set elements like e.g. integers somewhere in this function, all "'a"s there would unify to this type. This makes it impossible that we can accidently mix incompatible instances of sets, because there is only one (since explicitly bound) version of "'a". If we don't restrict the type of "'a" in the function body by using values of this type in specific contexts, it seems we can't do evil things either. Note that you cannot return values from functions if the type of these values is defined in a local module only (again, because the type couldn't be identified outside anymore). But returning values of types bound outside (also ones of type 'a) should be perfectly ok, n'est-ce pas? > I thought you could never have type variables on the right hand side if > they were'nt also on the left? Well, the requirement is that the type variable be bound so as not to lose track about its true identity. I am not an expert in type systems so maybe I just don't see other problems. At least it seems to me that a relaxation (generalization?) of the typing rules here would work fine. In any case, the current error message is obviously misleading, because 'a is really bound. > Besides, currently ML type annotations are without teeth, as you are > well aware; as a translator of Okasaki's algorithms you surely miss > polymorphic recursion. Sure, but as I said, I think your argument concerning mandatory type declarations is a different issue. Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr