Pierre Weis wrote:
> - a value of type row is in fact a concrete integer (it is not hidden in any
>   way),

But you cannot apply integer operations to it, so it is not a normal 
concrete integer, right?

> - a value of type row can only be created by the make function defined in the
>   implementation of the module that defines the private type,
> - a value of type row can be projected out of type row to a value of type int
>   with a ``no-op'' identity function (I called it from in the example).
> 
> So, no: a value of type row is not of type int and you need a marker to
> indicate the projection (for the time being the marker is a (identity)
> function call to let the implemention as simple as possible, but a sub-typing
> constraint makes sense and we can provide it if this is considered clearer).

Now I'm lost :-)

Can you show an example where replacing all "type t = private ..." 
definitions by "type t" changes a well-typed program into an ill-typed 
one?   I understand that if private types create real subtypes (w.r.t. 
:>) then they are different than abstract types, but otherwise, I don't 
see the difference for the type-checker.

-- Alain