Version française
Home     About     Download     Resources     Contact us    
Browse thread
Closed variants, type constraints and module signature
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] Closed variants, type constraints and module signature
From: Philippe Veber <philippe.veber@googlemail.com>
>> Constrained types have their uses,
> 
> which are, in brief ? Now I can't see a typical use for closed polymorphic
> variant types (I mean types of the form 'a t constraint 'a = [< ... ])

A typical use would be for objects, particularly when representing
virtual types (see the advanced part of the tutorial, in the reference
manual).
Another application is to use a record notation for type variables:

  type 'r t = .... constraint 'r = < env:'env; loc:'loc; typ:'typ; .. >
 
This way you can share multiple type parameters at once, and even
allow transparent addition of new parameters. This was not the
original goal of constraints, but I find it handy.

I have no immediate example with polymorphic variants, but your
arguments about scalability are valid: in some cases, constraints
allow more compact types. But at a cost.

>> but I find them often confusing as
>> the type variable you write is not really a type variable.
>>
> why isn't it the case ? Aren't they simply type variables restricted to a
> finite number of types ?

Yes they are constrained type variables.
But the problem is that the constraint is left implicit.

For instance, if somewhere you have defined

  type 'a t constraint 'a = [< `a | `b]

and inside an interface you write

  val f : 'a t -> int

the real meaning is

  val f : [< `a | `b] t -> int

I.e., you are hiding something.

This is not the same thing as type abbreviations, because constraints
are applied from the outside, while abbreviations just have to be
expanded.

Jacques Garrigue