Daniel Bünzli wrote: > Le 30 oct. 08 à 21:18, David Allsopp a écrit : > > > Shouldn't I now be able to say: > > > > string_of_int x;; > > I don't think so. According to the manual [1] the only thing you can > do on private types is pattern match or project their fields. I > doesn't mean your type can be substituted by int.
Strictly speaking the manual says that you can't construct values directly (you can construct other values which contain private types, though, so it's not limited to pattern matching or projection). > > [1] http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#htoc99 Thanks for this - although it's a link to an OCaml 3.10 manual so not applicable here it did point me to the correct chapter in the OCaml 3.11 manual (I'd been looking in Part I of the manual and given up). What I should have written is string_of_int (x :> int) Though that does make me wonder why the coercion is mandatory. What happens if I *want* to allow the use of M.t values as though they were ints and only want to guarantee that they come from a specific sub-set of the integers (I'm thinking of database row IDs which is what I want to use them for)? Assuming that the type abbreviation doesn't contain type-variables, would there be anything theoretically preventing the inclusion of two keywords: type t = private int (* can be used as though it were an int *) type t = very_private int (* requires a coercion to be used an int *) Or are there some very obvious programming gotchas that I'm missing if the need to write the coercion were relaxed? The important point to me would seem to be that if I say: x + 1 then I get the *int* 1 and not the *M.t* value 1. As it stands, I can't see a huge amount of difference, given that you have to write the coercion everywhere, between a fully abstract type and a function M.getValue : t -> int and a private int type. (I'm assuming that if M.getValue is defined as %identity then the compiler would optimise out the calls to it... of course if that isn't the case than private ints are already one stage better!) And one final thought - given that you can't assign to mutable members of private record types, isn't a bit strange that you can change the contents of private string values? Wouldn't having type t = private string where character access is not possible give some people the immutable strings they've been asking for in the past? David _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
