Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] Type variables won't generalize
[ 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@k...>
Subject: Re: [Caml-list] Type variables won't generalize
From: "Ryan Tarpine" <>
> Thank you; that was the explanation I was waiting for!  My next question is 
> whether or not there is some non-typesafe route around this.  Could I use 
> Obj.magic to store different data types in one field, as long as I keep 
> track of what type is really there (e.g., have a second field that would 
> store a number representing the type) so I can cast back later?  Sorry if I 
> keep finding myself longing for the "void*" C-ism!

A well known solution to this problem is to use exceptions to hold

  exception A of int
  exception B of bool

All exceptions define a different constructor, and they are all of
type exn.

But you might rather want to analyze why you want such a behaviour.
Why do you need to store such a versatile data? Note that you can use
polymorphic variants to handle extensible datatypes, as long as you
are writing in a purely functional way. And even without using this
kind of polymorphism, ML datatypes allow you to easily (and safely)
handle unions (sums), so that the idiom you're looking for can be
avoided. If you need parameterization, you can also look for
parametric types and/or functors.

I cannot give you an universal solution, because it depends very much
of your concrete goal. But trying to dodge the problem is probably not
the right way to go.

Jacques Garrigue
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: