Pierre Weis wrote:
> Values of a private type abbreviation are concrete in the sense that they are
> public and not hidden to inspection. 
> 
<SNIP>
> No, you must explicitely project row values to int values (even if
> this is an identity):

I guess I don't understand what you mean by "public and not hidden to
inspection".  To a programmer using such a type, the values don't seem
public.  Do you only mean that to the compiler sees the full type (for
optimization purposes), or something more?

> The function call overhead can be avoided easily, if the from function is
> provided by the compiler or if we use a sub-typing constraint row :> int.
> 
I'd love to use subtyping constraints more than functions.  Applying a
function *could* do some other work or massage the value it gives to me,
whereas a compiler cast seems to indicate what's happening better.  It
also doesn't depend on any cross-module inlining magic that may or may
not happen.

> On the other hand, the construction you proposed also applies to abstract
> types: we need module to define an abstract type; we can have something
> lighter such as a direct abstract type definition:
> 
> type rat = abstract {
>      numerator : int;
>      denominator : int;
>   } with
> 
>   let make_rat n d = ...
>   and numerator {numerator = n} = n
>   and denominator ...
> 
>   let plus_rat r1 r2 = ...
>   let mult_rat r1 r2 = ...
> 
>   ...
> 
This example seems like a great time to use a module and an abstract
type: there's lots of functions that deal with the data in a way that
they all need to use its internal representation.  But there's a use for
private copies of builtin types, possibly with restrictions on their
construction, and it seems that *this*

> Given that the injection function (the make function or the constraint part
> of your construction) must enforce arbitrarily complex invariants, we may
> need a module for private abbreviation as well (imagine for instance a
> private abbreviation for prime numbers, that only injects into the prime type
> integer arguments that are indeed prime numbers: you may need some room to
> define the predicate!).
> 
let is_prime i = ... (* return true if prime, false if not *)
type prime = private int constraint is_prime

This seems to suffice for the example of primes.  For natural numbers, I
don't see any advantage of having a private type vs. an abstract type,
so using a module to encapsulate that type makes more sense to me.

I might point out that supporting arbitrarily complex invariants, while
theoretically satisfying, might not be necessary.  I'd imagine that 90+%
of actual uses of this pattern fall in the case of "simple range
restriction", and taking care of those well changes the approach
significantly.  I like the Perl idea of "make the common things easy,
and the hard things possible".

> Thank you for your suggestions.
> 
> Best regards,
> 

Thank *you* for treating my naive and amateur suggestions as if they had
worth.

All the Best,
Eric