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

[Edgar Friendly <thelema314@gmail.com>]

Pierre Weis wrote:
> In the next version of the compiler, you will have an extension to the
> definition of types with private construction functions (aka ``private''
> types) that just fulfills your programming concern: in addition to usual
> private sum and record private type definitions, you can now define a type
> abbreviation which is private to the implementation part of a module (see
> note 1).
> 
At first glance, this improvement does satisfy my concerns, but I think
it still falls short of optimal in ways that seem easy to fix.

> Since the values of a private type are concrete, it is much easier for the
> programmer to use the values of the type abbreviation.
> 
This concerns me - I'd like to require explicit casting/coercion to
create or use the internal value of the abstract type, maybe with an
exception for literals.  Could you elaborate on this?

> This solution does not require any additional tagging or boxing, only the
> usage of injection/projection function for the type. As for usual private
> types, the injection function is handy to provide useful invariants (in the
> row type example case, we get ``a row value is always a positive integer'').
> 
With a bit of low-level support, I imagine it not difficult to implement
the following:

type row = private int constraint (fun i -> i >= 0)

such that the compiler uses the provided constraint function to check
any (x :> row) casts, throwing an exception(?) on false.  This solution
wouldn't involve the module system just to have positive integer types,
and gets rid of the function call overhead on 'from'.

> In addition, the private abbreviation is publicly exposed in the interface
> file. Hence, the compiler knows about it: it can (and effectively does)
> optimize the programs that use values of type row in the same way as if the
> type row were defined as a regular public abbreviation.
> 
Does this mean I can do:

let one (r:row) = r+1
let onea (r : row) = r = 1
let two (r:row) (i:int) = r+i
let three : row -> string = function 3 -> "three" | _ -> "not three"

> Last but not least, being an instance of the identity function, the from
> projection function is somewhat generic: we can dream to suppress the burden
> of having to write it for each private type definition, if we find a way to
> have it automatically associated to the new private type by the compiler.
> 
The use case for this feature is restricted construction to enforce
invariants, no?  Anything more complex should probably be totally
abstract and not simply private.  In which case, the constraint keyword
seems an effective way to tell the compiler what to do, and just let :>
coercions do their magic.

E.