Re: [Caml-list] [ANN] ocamlopen 1.0.2

[Leo P White <lpw25@cam.ac.uk>]

>1. You link to a paper by Andres Löh and Ralf Hinze, how close are you
>of their proposal?
>They mention open datatypes and functions, you propose open datatypes,
>but not open functions? That would be understandable because open
>pattern matching is a bit fishy (best-fit matching etc...).

I think that my open datatypes are basically the same as they propose, 
which is pretty much the same as the behaviour of exn in OCaml. 

>2. What is the difference between your "open" and "extensible"
>datatypes? The visual difference is the present of initial
>constructors in extensible cases, but you apparently make much finer
>distinctions.

This complication arises from the existence "extensible variant 
declarations", and is one of the reasons that I think the extension 
is probably better without them.

Basically, by an "extensible" type I mean one for which not all the 
constructors are given in the type declaration. Obviously all abstract 
types in a signature are extensible, because they may be implemented 
using a variant type. My extension allows variant type declarations to 
also be made extensible using the syntax:

type Foo = A | B of int | ..

Note that this extensibility cannot be hidden by a signature, the 
compiler needs to know if a variant is extensible in order to properly 
implement pattern matching.

By an "open" type I mean one that is allowed to be extended using an 
extension definition. Only extensible types can be declared open, 
becuase an extension definition adds constructors to a type that are 
not mentioned in its declaration. Unlike extensibility, the openness 
of a type can be hidden using a signature.


>3. What is the semantics of making a *constructor* private? My
>intuition of private types is that (type t = private u) generates a
>new type t that is a strict subtype of u (values of type t can be
>coerced into u, but not the other way around). This intuition does not
>hold anymore if some constructors are marked private, but not the
>other.

As Alain said, making a constructor private allows it to be used for 
pattern matching but not to create a value. This is an alternative 
intuition for how private variant types already work. 

I think that allowing private extensions could definitly be useful. 
Borrowing Alain's example of a messsage bus, if a message producer 
used a private message constructor then it could enusre that it was 
the only component producing messages with that constructor.

Note that the extension does not allow private abstract types to be 
declared open, because this would break the standard intuition for 
them.

However, it does allow private variant declarations to be made open 
and treats this as meaning that each of its ordinary constructors 
is private, but that public extensions *can* still be created and 
used in positive positions. I think that this is a bit of a muddle, 
and possibly another reason that extensible variant declarations 
should be left out.

>4. When would you say that one should use polymorphic variants rather
>than your open datatypes? (I know how to argue in the other direction:
>unique constructors make for better error messages.)

A good reason for using polymorphic variants is to create multiple types 
that share constructors. For instance a compiler might want one type to 
represent expressions and another to represent constant expressions. 
Using polymorphic variants constant expression values could be used 
directly as expressions values. This wouldn't be possible using open 
datatypes.

Note that there are other reasons to use open datatypes over polymorphic 
variants: they can be used properly with references, they can be 
controlled using modules and they can be GADTs.

>5. What are the implications of your patch at the runtime / data
>representation level? Could you elaborate a bit more on "a new tag to
>represent extensions"? Have you conducted performance measurements?

Just like exceptions, they are represented as constructors whose 
first field points to an address that is allocated by the extension 
definition to represent that extension. They have a special tag value 
so that structural equality knows to compare the first fields by 
address. Note that this is exactly what is required to fix the bug 
with structural equality on exceptions (4765).

I haven't conducted any performance measurements, but using extensions 
should be similar in cost to using exceptions. The ordinary variants 
in an extensible variant declaration should perform similarly to any 
other ordinary variants. 

Thanks for the interest.

Regards,

Leo