Re: [Caml-list] Compiler feature - useful or not?

[Edgar Friendly <thelema314@gmail.com>]

Pierre Weis wrote:
> 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

Other than piggybacking on the private row types work by J. Garrigue and
probably simplicity of implementation, does there exist a reason for
involving the module system in this mechanism?

At the basic level, creation and projection will always be identity
functions (except that creation can throw exceptions), so it seems
reasonable to elide that repetitive code.  For more complex examples (a
private type with more functions that work on the internal
representation of that type), since the representation is already
exposed, it seems appropriate to just let the client implement those
functions through the identity accessors.  It'd probably be safer than
doing so in the Row module, because the compiler could enforce the
creation invariant in those functions instead of allowing them to bypass
the 'make' function.

Once all these functions are removed from the module all that's left is
the type definition and the creation constraint.  Am I missing something?

E.