Version française
Home     About     Download     Resources     Contact us    
Browse thread
grammar for class types, reraised
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Hendrik Tews <tews@t...>
Subject: Re: grammar for class types, reraised
Hi,

   From: Jerome Vouillon <Jerome.Vouillon@inria.fr>
   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