grammar for class types, reraised

grammar for class types, reraised

[Hendrik Tews]

Hi,

on May 14th I sent the appended message to the ocaml mailing
list. Unfortunately I haven't seen any answer so far. Could one
of the developers please answer these questions (or give some
pointers)?

1. What is the difference between

# class type b = [int, string] a;;

and 

# type c = (int, string) a;;  

assuming some class type a with two type parameters?

And why do I have to use different parentheses in both cases?
(Yes, I know, it's what the manual says, but I would expect that
one kind of parentheses should be enough for all kind of type
parameters. )

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;;

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

(Yes, it is possible to use the < ... > notation, but it is not
possible to use # with such types.)

Bye,

Hendrik

Re: grammar for class types, reraised

[Jerome Vouillon]

On Mon, Jun 14, 1999 at 10:04:32AM +0200, Hendrik Tews wrote:
> 1. What is the difference between
> 
> # class type b = [int, string] a;;
> 
> and 
> 
> # type c = (int, string) a;;  
> 
> assuming some class type a with two type parameters?

The former expression also defines a class type and a type #c.

> And why do I have to use different parentheses in both cases?
> (Yes, I know, it's what the manual says, but I would expect that
> one kind of parentheses should be enough for all kind of type
> parameters. )

It was not possible to use regular parentheses for class parameters,
as the grammar would have been too hard to parse. Consider for
example :
  class d = (a b : t)
  class d = (a b) d
On the other hand, it was not acceptable to change the grammar of
types. That's why there are two different kind of parenthesis.

> 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.

> 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
> 
> (Yes, it is possible to use the < ... > notation, but it is not
> possible to use # with such types.)

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). This would make the
implementation even more complicated.

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
    class type a = object method m : b end
    and
    type b = Node of a | Tree of b * b
into
    type 'a b = Node of 'a | Tree of b * b
    class type a = object method m : a b end

-- Jérôme

Re: grammar for class types, reraised

[John Prevost]

Jerome Vouillon <Jerome.Vouillon@inria.fr> writes:

> 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). This would make the
> implementation even more complicated.
> 
> 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
>     class type a = object method m : b end
>     and
>     type b = Node of a | Tree of b * b
> into
>     type 'a b = Node of 'a | Tree of b * b
>     class type a = object method m : a b end

My situation was somewhat more obscene, and would've required this:

type ('foo,'bar,'baz,'qux,'blatz,'zuttle,'potz,...) cast =
 | Foo of 'foo
 | Bar of 'bar
 | ...

class type node = object method downcast : (foo,bar,...) cast end
and bar = object ... end
...

The whole point of the excercise was to have a downcast method for a
set of specific classes, in a type-safe way.  I eventually wrote code
using < ... > for all of the types.

John.

Re: grammar for class types, reraised

[Hendrik Tews]

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

Re: grammar for class types, reraised

[Jacques GARRIGUE]

From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>

>    From: Jerome Vouillon <Jerome.Vouillon@inria.fr>

>    > 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.

In fact, you can already do that:

class type ['a, 'b] a = object method m : 'a -> 'b end
class type ['a] c = object
  inherit ['a,string] a
  constraint 'a = int
end

Remark also that inheritance at the type level does not presuppose
inheritance at the value level, so this should be general enough.

	Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>