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