Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] type var in functor instance?

0 views
Skip to first unread message

skaller

unread,
Sep 18, 2004, 10:17:00 AM9/18/04
to caml-list
Is it possible instantiate a functor with a module
containing a type variable? I have a Set with t = int,
and I now need 'a * int..

--
John Skaller, mailto:ska...@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

-------------------
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

skaller

unread,
Sep 20, 2004, 11:45:33 AM9/20/04
to Jean-Christophe Filliatre, caml-list
On Mon, 2004-09-20 at 21:58, Jean-Christophe Filliatre wrote:

> skaller writes:
> > Is it possible instantiate a functor with a module
> > containing a type variable? I have a Set with t = int,
> > and I now need 'a * int..

> Various unsatisfying solutions have been proposed, among which
>
> - to make a copy of Set with an additional type parameter eveywhere (I
> attach such a module below. Beware: this is an old version of Set)

Hmmm. I see. I think I understand why this is needed.
Dependent typing problem? Set depends on element...

> - to make an unfunctorized version of Set that uses Pervasives.compare,
> thus polymorphic

This is already in the standard distro for Hashtbl.
Why not for Set and Map as well? Why is this
unsatisfactory?

I actually use heaps of Hashtbl of polymorphic kind
and am ready to switch some over to an functor instance
with key type int -- most of my tables use int keys
and I hope to gain some performance and reasoning ability.

The duplicate interface has let me experiment rapid
prototyping style, then lock down the typing a bit,
leaving the raw function names and semantics the same.

I think that's nice -- one reason I use Hashtbl
even when Set or Map would be better.

Daniel Bünzli

unread,
Sep 20, 2004, 4:16:45 PM9/20/04
to caml-list
Hello,

Accidentally I'm running into the same problem. I'd like to have a
polymorphic Hashtbl that uses physical equality. Using Hashtbl.Make is
not possible since the type t of the input signature HashedType has no
variable.

More precisely I would like to have a key with the following type

type 'a 'b key = 'a option * 'b option

and the following equal function,

let equal k k' = match k, k' with
| (Some x, y), (Some x', y') -> if x == x' then y = y' else false
| _, _ -> k = k'

which tests for physical equality when the first component of the key
is "Some" in both keys.

Any hints besides those already suggested ?

Daniel

Jon Harrop

unread,
Sep 20, 2004, 4:23:37 PM9/20/04
to caml-list
On Monday 20 September 2004 16:43, skaller wrote:
> > - to make an unfunctorized version of Set that uses Pervasives.compare,
> > thus polymorphic
>
> This is already in the standard distro for Hashtbl.
> Why not for Set and Map as well? Why is this
> unsatisfactory?

You mean Hashtbl uses a polymorphic hash?

I think it would be productive to factor the tree out of set and map.

What if someone released backwards-compatible replacement modules for List,
Array, Set, Map etc. which implemented this stuff? Then package maintainers
could replace them if they liked the alternative implementations and coders
could assume their existence. Maybe.

> I actually use heaps of Hashtbl of polymorphic kind
> and am ready to switch some over to an functor instance
> with key type int -- most of my tables use int keys
> and I hope to gain some performance and reasoning ability.

IMHO, hash tables are a bit less safe than sets and maps because hash tables
make it easier to apply a structure-based polymorphic function incorrectly,
e.g. to many abstract types, when a semantically meaningful (e.g. comparison)
function should be used. For example, I don't think a hash table of sets
would be very useful...

This strikes me as an important way to screw up ML programs and, consequently,
it would be nice to address this. I've been trying to think of a solution but
all I've come up with is: you could enforce the use of an appropriate
comparison by making everything an object with its own compare method. But
then you're going back to dynamic typing. Perhaps phantom types could do
it...

Cheers,
Jon.

0 new messages