Re: [Caml-list] syntax of private constructors in CVS version

[Pierre Weis <pierre.weis@inria.fr>]

> So, when do we get views to solve this problem for abstract types?  If 
> pattern matching is so great (which it is) it seems a crime to not allow it 
> on abstract types (another great feature).  To make an american candy joke, 
> peanut butter and chocolate taste great together!
> 
> Chris

Hem, the introduction of the private type feature was just my answer
to this question. I wanted to get the security of type abstraction
without the drawback of loosing pattern matching.

Put it another way:

-- regular data types are concrete, you can freely create their values
with constructors or labels, you can inspect their values via pattern
matching,

-- private types are ``semi concrete'', you cannot freely create their
values (you are obliged to use their construction functions) but you
can still inspect their values via pattern matching,

-- abstract types are not concrete, you cannot freely create their
values (you are obliged to use the construction functions they
provide) and you cannot inspect their values via pattern matching (you
are also obliged to use the inspection functions they provide).

Yet another way (coarse and oversimplified view (:)):

-- concrete types are freely readable/writable data types,

-- private types are freely read only data types,

-- abstract types are nor freely readable nor freely writable data types.

And some specific advantages of each:

-- concrete types give you the maximum freedom (no invariants to
respect, no burden with construction functions), but you get a maximum
dependancy on the implementation (modification of the concrete type is
visible all over the place). Addition of operators is easy.

-- abstract types give you the maximum security (strict enforcement of
invariants by the compiler), no dependancy on the implementation that
can be modified as required by the implementor of the type, no
possibility of confidentiality leaks: the contents of a value that can
have truely hidden parts. Addition of operators is difficult or impossible.

-- private types give you the same security as abstract types for
invariants and the same facility for the addition of new
operators. You loose the ability to hide parts of values.

In my mind, private types give you for free a lot of useful facilities
that you could have with views, while retaining invaluable, both
conceptual and implementationnal, simplicity.

You may be right that eventually Caml could still need an extra
feature as powerful and complex as views for abstract data types, but
for the time being let's start and experiment with this now available,
simple, and effective feature. It has already proved to be incredibly
powerful and efficient for some applications. So let's go and discover
where we still need more :)

I mean, try it :)

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners