Hi Chris,

This only becomes an issue when the data being associated with a
constructor would need to be boxed.  Since an int doesn't require any
boxing, the type 'foo = Foo of int' will work exactly as expected.

Boxing/unboxing optimizations can be very subtle. The most important
example I can think of is computation with complex numbers.  Is it better
for the the representation to be as a pair of floats in one structure or
as two separate floats?  Different parts of a program may do better with
one representation instead of the other.

As far as I understand, the compiler could choose a representation for
variants and insert the necessary transformation code to hide the issue
from the programmer entirely.  I haven't thought about the issue much so 
there could be a real problem that I'm not seeing. From what I remember,
SML does not make this kind of syntactic distinction.

Patrick

On Wed, 4 Apr 2001, Chris Hecker wrote:

> 
> >I would certainly like it if Caml could:
> >  1) Treat this entirely as an optimization issue and not make a syntactic
> >distinction.
> 
> I agree.  Is there a reason why it's done this way?  I guess you need to
> be able to bind another name to the tuple independently, and for that to
> work you need it to be another block on the heap.  Maybe it's not
> possible in general to do the right thing. 
> 
> But wait, why isn't this a problem even with normal non-tupled values?
> 
> In other worlds, how does type foo = Foo of int work when I take a
> reference to the int?  It has to know I'm refering to the int to GC
> correctly.  Why is the tuple version any different? 
> 
> I'm confused.
> 
> Chris
> 
> 

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