Re: [Caml-list] classes vs modules

[Brian Rogoff <bpr@best.com>]

On Sun, 27 May 2001, Markus Mottl wrote:
> Out of curiousity, would it be unsound to allow functions like the
> following:
> 
>   let f (cmp : 'a -> 'a -> bool) =
>     let module SomeSet =
>       Set.Make (struct type t = 'a let compare = cmp end) in
>     ()

You can do this now if you make a PolySet module by copying the
"monomorphic" implementation from the stdlib, changing elt and t to 
'a elt and 'a t and, using that instead of Set, something like:

let f (cmp : 'a -> 'a -> bool) =
  let module SomeSet =
    PolySet.Make 
      (struct type 'a t = 'a let compare = Pervasives.compare end) in
  ()

I use something very much like that in a few places, for example a
"uniquify" function on lists which eliminates duplicates.

I ended up creating polymorphic modules for a few of the stdlib modules on 
account of that old issue about functor instantiations recursive with a
type definition, so as to perform the ugly parameterization hack to
sidestep this ML limitation, but they are useful elsewhere too.

> The compiler complains with:
> 
>   File "foo.ml", line 2, characters 49-51:
>   Unbound type parameter 'a
> 
> This, however, is not true (in any case): 'a is bound by the explicit
> function annotation.

I thought you could never have type variables on the right hand side if
they were'nt also on the left? Besides, currently ML type annotations are 
without teeth, as you are well aware; as a translator of Okasaki's
algorithms you surely miss polymorphic recursion.

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr