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