Version franēaise
Home     About     Download     Resources     Contact us    
Browse thread
Compiler feature - useful or not?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Martin Jambon <martin.jambon@e...>
Subject: Re: [Caml-list] Compiler feature - useful or not?
On Thu, 15 Nov 2007, Yaron Minsky wrote:

> Most of what you said about quotient types made sense to me, but I must
> admit to being deeply confused about the nature of the change to the
> language.  Consider the following trivial module and two possible
> interfaces.
>
> module Int = struct
>   type t = int
>   let of_int x = x
>   let to_int x = x
> end
>
> module type Abs_int = sig
>   type t
>  val of_int : int -> t
>  val to_int : t -> int
> end
>
> module type Priv_int = sig
>   type t = private int
>   val of_int : int -> t
>   val to_int : t -> int
> end
>
> So, what is the difference between (Int : Abs_int) and (Int : Priv_int)?

Just like for other constructors of concrete types, "private" makes them 
read-only, i.e. you can use them only in pattern-matching.

You can write
   match (x : Priv_int.t) with 0 -> true | _ -> false

But not
   (x : Priv_int.t) = 0


> For instance, can I write (Priv_int.of_int 3) + (Priv_int.of_int 5)?

No, Priv_int would have to define its own Priv_int.(+) function.

>  Can
> you point to anything concrete I can do with the private version that I
> can't do with the abstract version?  Is there any expression that is legal
> for one but not for the other?

You can do some pattern-matching over private versions of ints, strings, 
chars, arrays, builtin lists, polymorphic variants, in addition to records 
and variants, without the risk of passing such values to the wrong 
function (if such wrong function expects a real "int" for instance).

You can't do any useful pattern matching with abstract types.


Martin

--
http://wink.com/profile/mjambon
http://martin.jambon.free.fr