Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] le neophyte et les modules, types parametres
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alain Frisch <frisch@c...>
Subject: Re: [Caml-list] le neophyte et les modules, types parametres
On Wed, 25 Apr 2001, Francois Thomasset wrote:

> Question: how to use a parameter type in a module, cf example above

The same problem has already been discussed on this list (or maybe on
comp.lang.{ml,functional}, not sure), and I think there is no good
solution for the moment. 

This issue struck me again just two hours ago. I wanted to build sets
or hash tables over "stamped" values (using the stamp for
comparison/hashing), so I defined a module whose signature is:

module Stamp :
sig
  type 'a t = { stamp : int; data : 'a }

  val build : 'a -> 'a t
  val data  : 'a t -> 'a
  val compare : 'a t -> 'a t -> int
  val hash  : 'a t -> int
  val equal : 'a t -> 'a t -> bool
end

(I don't want Stamp itself to be a functor, because of the lack of
recursivity between modules).

But then  (Set.Make(Stamp)) doesn't work. There would be no problem
to have a generic implementation of Set on parametrized ordered types.
But then you may want to use it with types parametrized with two type
variables, etc ... The solution is presently to copy the
implementation from stdlib/set.ml. The *only* modification is to replace
in the implementation:
 type t = Empty | Node of t * elt * t * int
with
 type 'a t = Empty | Node of 'a t * 'a elt * 'a t * int
or
 type ('a,'b) t = Empty | Node of ('a,'b) t ...
and so on.

The specification must me changed accordingly. It seems that the
transformation is completely automatic and syntactic.

Would there be any problem to accept in functor applications modules whose
types have extra parameters, reflecting adequate modification on the
result ?  (this is only a typing problem; as far as I understand it,
there is absolutely no problem for runtime; adding type parameters
implies no new coercion of runtime representations)


-- 
  Alain Frisch

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