> Pierre Weis wrote:
> >a private type is not an abstract type but a concrete type.
> 
> I guess I got a wrong intuition of the new feature because of the "from" 
> function in your example. Is it the case that a value of type "abstract 
> int" can always be used as a value of type "int" automatically (you 
> mention that it is ok for pattern matching at least)?

If we stick to the row example of positive values, we get:

- a value of type row is in fact a concrete integer (it is not hidden in any
  way),
- 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).

Best regards,

-- Pierre