Re: [Caml-list] (int * int) <> int*int ?

[Brian Hurt <bhurt@spnz.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2639 bytes --]



On Thu, 23 Feb 2006, Frédéric Gava wrote:

>> This isn't correct- the same problem shows up in the difference between:
>> int*int*int and int*(int*int)- i.e. the difference between (1,2,3) and
>> (1,(2,3)).  In the first case (in both examples) I have a three element
>> tuple, in the second case I have a two element tuple whose second element
>> is also a two element tuple (and thus I have the layer of indirection).
>
> Hum, no...here we have three (int) or two (one int and one pair) elements.
> In the concrete type case, we have two elements (and both cases pair because
> in both case A (2,3) works fine) and it is a problem of curryfication which
> is not justify. (int*int*int)=int*int*int everywhere and also

No.  There are cases where (int*int*int) is not the same as int*int*int. 
Specifically, int*(int*int*int) is different than int*int*int*int.

So, in terms of representation:
type t = A of int * int
is represented in memory as
     tag * int * int
while
type t' = B of (int * int)
is represented in memory as
     tag * (int * int)
where in both cases tag is the tagging information added by the compiler. 
Note that in the first case it's a three word structure (two ints and a 
tag), while in the second case it's a two word structure (a tag and a 
reference to a tuple of two ints).

You keep trying to assume that the parentheses are purely syntactic-
they're not.

>>  I can often
>> save copying information (and storing the duplicate information) if I can
>> add the level of indirection- this is important if I'm copying the
>> information a lot.  On the other hand, if the information isn't being
>> duplicated a lot, then I can save memory by not having the extra level of
>> indirection.
>
> This is why I thinks that the case (int*int) is not justify if there is no
> partial application of the concrete constructors (because the level of
> indirection could be avoid at the time of pattern-matching : you quickly
> modify the data of the concrete type to have a tuple...).

No.  Because in the case of B, I can snag the tuple as an independent 
peice of data.  For example, I can write:
 	let f = function B x -> fst x;;
and it works.  On the other hand, if I try to write:
 	let g = function A x -> fst x;;
this doesn't work- because the "tuple" in A doesn't really exist as an 
independent data structure (it's been unboxed).  Here, Ocaml is refusing 
to allow a pointer into the middle of a structure (the GC algorithm thanks 
you), and doesn't want to have to allocate a tuple to hold x (this 
seriously complicates pattern matching).

Brian