From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id AAA16798 for caml-redistribution; Wed, 23 Jun 1999 00:05:41 +0200 (MET DST) 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 SAA08662 for ; Tue, 22 Jun 1999 18:59:45 +0200 (MET DST) Received: from tcs.inf.tu-dresden.de (tcs.inf.tu-dresden.de [141.76.75.119]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id SAA11821 for ; Tue, 22 Jun 1999 18:59:44 +0200 (MET DST) Received: from ithif20.inf.tu-dresden.de (ithif20 [141.76.75.120]) by tcs.inf.tu-dresden.de (8.9.1a/8.9.1) with SMTP id SAA04121 for ; Tue, 22 Jun 1999 18:58:32 +0200 (MET DST) Received: by ithif20.inf.tu-dresden.de (SMI-8.6/SMI-SVR4) id TAA21025; Tue, 22 Jun 1999 19:00:22 +0200 Date: Tue, 22 Jun 1999 19:00:22 +0200 Message-Id: <199906221700.TAA21025@ithif20.inf.tu-dresden.de> From: Hendrik Tews MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: caml-list@inria.fr Subject: Re: grammar for class types, reraised In-Reply-To: <19990614233019.41897@pauillac.inria.fr> References: <199906140804.KAA01028@ithif20.inf.tu-dresden.de> <19990614233019.41897@pauillac.inria.fr> X-Mailer: VM 6.34 under Emacs 19.34.1 Sender: weis Hi, From: Jerome Vouillon Date: Mon, 14 Jun 1999 23:30:19 +0200 Subject: Re: grammar for class types, reraised [...] > 2. Why is it not possible to add type constraints to the first > kind of type abbreviation, like in > > class type ['a] c = ['a, string] a constraint 'a = int;; There is no real reason. I think I could add this quite easily to the language if you need this. The constraints are neccessary, if one wants to work with interface specifications, consider: ====== file types.ml ========= class type ['a, 'b] z_type = object (* method declarations *) end ====== file classes.ml ======== class ['a, 'b] z_class : ['a, 'b] z_type = object (* method definitions *) end =============================== In a realistic example you get soon type constraints in the class definition z_class between the type parameters. This is not a problem in the code above (because the type annotation ['a, 'b] z_type is only required to be more general), but it gets one, if you try ====== file classes.mli ======= class ['a, 'b] z_class : ['a, 'b] : z_type =============================== If z_class has constraints, then it does not match the more general type z_type and the module is rejected from the compiler. > 3. (To re-raise a question from John Prevost which has never been > addressed:) Why is it not possible to mix type definitions and > class type definitions like in > > # class type a = object method m : a end > # and > # type b = Node of a | Tree of b * b This would probably be possible, but it is not trivial. And then, you would probably expect to be able to include in the recursion other construct, such as value definitions (for instance, if a function using the type b is used by the class a). No. I only want to mix class types (not classes) and data types in one recursion on the type level. A similar recursion on the value level (i.e. mixing function definitions and classes in one recursion) is not required, because you can already program recursions between functions and methods in a natural way (if you only manage to declare the types). On the other hand, you can get rid of the mutual recursion by adding a type parameter to one of the type. For instance, you can change Yes. But this works only for toy examples. If you follow this approach in a real project you would soon end up in a situation, where every type definition takes more than 5 type parameters (remember, that you also have to use a type variable, for every method, which gets covariantly overridden). This way you get an explosion of type parameters, which is not manageable. Just a note, why I think it is so important to have these mixture of class types and data types: Ocaml is one of the few languages, which have inductive data types _and_ class types. Inductive data types and recursive functions are the natural way to program data structures. And class types are the natural choice, if you want to model processes or reactive systems with some black box behaivior. From this one could hope, that it is possible to model systems in ocaml as they occur in practice (ie. data structures, that organize processes, where the processes itself hold complex data structures again, which are used ... ). But syntactic distinction of class types and data types makes this impossible. Bye, Hendrik