From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA31662 for caml-redistribution; Wed, 13 Jan 1999 12:22:28 +0100 (MET) 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 UAA20134 for ; Tue, 12 Jan 1999 20:20:41 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id UAA26670 for ; Tue, 12 Jan 1999 20:20:39 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id UAA12125; Tue, 12 Jan 1999 20:20:31 +0100 (MET) From: Markus Mottl Message-Id: <199901121920.UAA12125@miss.wu-wien.ac.at> Subject: Re: Using modules and classes recursively To: bpr@best.com (Brian Rogoff) Date: Tue, 12 Jan 1999 20:20:31 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: from "Brian Rogoff" at Jan 12, 99 10:49:59 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis > On Tue, 12 Jan 1999, Xavier Leroy wrote: > > > Is it impossible to have modules and classes combined recursively? > > > > Currently, yes. A module definition cannot be mutually recursive with > > any other definition (type, class, or another module). This raises a > > number of difficult typechecking and compilation problems that are > > still largely open. I agree this is probably the most irritating > > restriction of ML modules. > > A similar restriction also exists in Ada, i.e., two package specifications > cannot "with" (open) each other. One workaround for the case where you > have mutually dependant tagged types (classes) in separate package specs > is to break the cycle by creating a dummy parent type for each of the > dependant tagged types and using those in place of the type which would > cause the problem, in this case a "foo_dummy_parent set" would replace foo > in the problem spots, foo would inherit from foo_dummy_parent and the > foos that go into the set would have to be coerced to foo_dummy_parent. > > I think this trick will work in OCaml too, but I haven't tried. > > -- Brian That would generally be a fine idea - I am sure it would work (I have also not tried yet)! But unfortunately this won't work with my classes, because they cannot be subtypes of their ancestor: they all inherit from another class that has a method with the "'self"-type in its signature. This "'self"-type is automatically redefined in every (sub-)class, so the signature of the child class does not match the one of its dummy parent class. It would only do so if this method didn't exist in the dummy parent, but unfortunately, I have to access this method for all objects in the set, so I cannot leave it away... My last posting about "subtypes and inheritance" dealt with this problem. Has already someone found a solution to this? - To me this is really a big shortcoming, because it does not allow me to build larger class hierarchies, where things like the "'self"-type or otherwise redefined signatures of methods are very likely to occur. Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl