[Caml-list] Type variables won't generalize

[Caml-list] Type variables won't generalize

[Ryan Tarpine]

I have an odd typing problem, odd because it occurs only when using ocamlc 
and not ocaml.  I've cut my code down to the following small snippet:

type 'a my_object = {
  partner : 'a my_object ref;
  data : 'a ref
};;

let rec object1 = {
  partner = ref object2;
  data = ref `PNone
}
and object2 = {
  partner = ref object2;
  data = ref `PNone
};;

That runs fine when passed to ocaml, but when I run it through ocamlc I get:

File "foo.ml", line 6, characters 18-66:
The type of this expression, _[> `PNone] my_object,
contains type variables that cannot be generalized

What's wrong with my code?  Thanks in advance!

Ryan Tarpine, rtarpine@hotmail.com
"To err is human, to compute divine.  Trust your computer but not its 
programmer."
  - Morris Kingston

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

-------------------
To unsubscribe, mail caml-list-request@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

Re: [Caml-list] Type variables won't generalize

[Ryan Tarpine]

>From: Remi VANICAT <vanicat@labri.u-bordeaux.fr>
>To: caml-list@inria.fr
>Subject: Re: [Caml-list] Type variables won't generalize
>Date: 04 Apr 2002 14:04:16 +0200
>
>...
>
>If you already know the types you can put in this field, you can use a
>new variant type :
>
>type multi =
>| Float of float
>| Int of int
>| Int2float of int -> float
>
>...
>

The problem is that I can't be sure of which types could be stored there.  
This record is meant to implement an object for an object-oriented language 
I'm trying to write.  The problem field stores primitives like ints and 
floats for Integer and Float classes, but in the case that later on I would 
like to add new primitives like Num.num through extension modules (e.g., not 
by modifying and recompiling the entire language) a normal variant won't 
work.  I unfortunately am having problems with typechecking when using 
polymorphic variants, so for now I am just going to use normal variants.

Thanks,

Ryan Tarpine, rtarpine@hotmail.com
"To err is human, to compute divine.  Trust your computer but not its 
programmer."
  - Morris Kingston

Ryan Tarpine, rtarpine@hotmail.com
"To err is human, to compute divine.  Trust your computer but not its 
programmer."
  - Morris Kingston

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

-------------------
To unsubscribe, mail caml-list-request@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

Re: [Caml-list] Type variables won't generalize

[Jacques Garrigue]

From: "Ryan Tarpine" <rtarpine@hotmail.com>
> 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
values.

  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 caml-list-request@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

Re: [Caml-list] Type variables won't generalize

[Ryan Tarpine]

>From: Francois Pottier <francois.pottier@inria.fr>
>Reply-To: Francois.Pottier@inria.fr
>To: caml-list@inria.fr
>Subject: Re: [Caml-list] Type variables won't generalize
>Date: Thu, 4 Apr 2002 09:36:38 +0200
>
>...
>
>That is precisely what you cannot do. If different modules were allowed to
>store different types into that field, type conflicts could occur. (Imagine
>one module chooses to write `A of int, and some other module attempts to
>read `A of int -> int. An integer would be cast into a function, leading to
>a crash.) In other words, to preserve separate compilation, the compiler
>forces you to restrict that variant to a certain set by declaring its type.
>The problem does not arise in the toplevel evaluator (ocaml) because it 
>does
>not perform separate compilation.
>
>--
>François Pottier
>Francois.Pottier@inria.fr
>http://pauillac.inria.fr/~fpottier/
>-------------------

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!

TIA,

Ryan Tarpine, rtarpine@hotmail.com
"To err is human, to compute divine.  Trust your computer but not its 
programmer."
  - Morris Kingston

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

-------------------
To unsubscribe, mail caml-list-request@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

Re: [Caml-list] Type variables won't generalize

[Remi VANICAT]

"Ryan Tarpine" <rtarpine@hotmail.com> writes:

> 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!

well, I don't really see the interest of such things.

If you already know the types you can put in this field, you can use a
new variant type :

type multi =
| Float of float
| Int of int
| Int2float of int -> float
....

otherwise, it seem (to me) that you may find better way of doing it
that using a "void*" C-ism.
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
To unsubscribe, mail caml-list-request@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

Re: [Caml-list] Type variables won't generalize

[Francois Pottier]

On Wed, Apr 03, 2002 at 08:37:02PM -0500, Ryan Tarpine wrote:
> 
> I would like to keep the 
> variant because I don't know what types of data will be stored in that 
> field, and I don't want to restrict it to a certain set.  I would like 
> modules in the future to be able to store different types without having to 
> recompile the whole program.

That is precisely what you cannot do. If different modules were allowed to
store different types into that field, type conflicts could occur. (Imagine
one module chooses to write `A of int, and some other module attempts to
read `A of int -> int. An integer would be cast into a function, leading to
a crash.) In other words, to preserve separate compilation, the compiler
forces you to restrict that variant to a certain set by declaring its type.
The problem does not arise in the toplevel evaluator (ocaml) because it does
not perform separate compilation.

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
To unsubscribe, mail caml-list-request@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

Re: [Caml-list] Type variables won't generalize

[Ryan Tarpine]

>From: Charles Martin <joelisp@yahoo.com>
>To: "Ryan Tarpine" <rtarpine@hotmail.com>
>Subject: Re: [Caml-list] Type variables won't generalize
>Date: Wed, 03 Apr 2002 15:19:25 -0800
>
>
>I'm sure there's a real answer to your question, but in cases like you 
>describe, I always create the records and then assign back into them.  
>Thus:
>
>...
>
>Also, maybe you want to use mutable fields instead of ref?
>
>Charles
>

Using the ref was a silly mistake, yes; that's what I get from moving from a 
single ref to a tuple of refs to a record for storing data as my program 
grew in complexity  :)  But, I'm guessing you did not run the code you 
suggested.  Ocamlc chokes on it in the same manner as my original code.  
Here's exactly what I just tried:

type 'a my_object = {
  mutable partner : 'a my_object;
  mutable data : 'a
};;

let object1 = {
  partner = Obj.magic 0;
  data = `PNone
};;

let object2 = {
  partner = Obj.magic 0;
  data = `PNone
};;

Without even assigning back (it makes no difference whether I do or not), I 
get the same error:

File "foo.ml", line 6, characters 14-58:
The type of this expression, _[> `PNone] my_object,
contains type variables that cannot be generalized

The polymorphic variant is conflicting somehow, and I don't know enough 
about the type system to figure out how to fix it.  I would like to keep the 
variant because I don't know what types of data will be stored in that 
field, and I don't want to restrict it to a certain set.  I would like 
modules in the future to be able to store different types without having to 
recompile the whole program.

Ryan Tarpine, rtarpine@hotmail.com
"To err is human, to compute divine.  Trust your computer but not its 
programmer."
  - Morris Kingston

Ryan Tarpine, rtarpine@hotmail.com
"To err is human, to compute divine.  Trust your computer but not its 
programmer."
  - Morris Kingston

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

-------------------
To unsubscribe, mail caml-list-request@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