there isn't any difference, is there, with unboxed tuples?

[Stefan O'Rear]

On Fri, Jan 04, 2008 at 09:36:33PM -0500, Isaac Dupree wrote:
> --> unboxed types in function results are automatically "lifted"... or what 
> was the term meaning they could be _|_, failing to terminate, (because of 
> the function-ness)?
>
> --> unboxed tuples are specially restricted to be only allowed, among 
> useful places, in function results.
>
> Therefore (... -> ( a, b, c ) ) and (... -> (# a, b, c #)) are identical, 
> assuming both are kind-correct (identical in terms of optimization and 
> semantics, not type equality, of course).  Is that right?  If so, there's 
> never an excuse to use unboxed tuples except to contain unboxed values 
> (because then you don't have the choice of using boxed tuples, which can 
> only contain boxed values of kind *).

Semantically, you are absolutely correct.  However, there is a very
subtle difference in sharing.

Consider these two functions:

foo (a,b) = (a,b)
bar tuple = tuple

These two functions are denotationally identical, but at runtime one
performs more allocations.  If we use unboxed tuples, then the caller
must always allocate if a tuple is needed; thus effectively we always
get the allocation behavior of foo.  That is, return unboxing is not
always an optimization!  However, it *is* always safe if the tuple is
constructed in the function itself, for then it could not possibly be
shared with anything.  Having explicit unboxed tuples in the language
allows this complexity to be moved out of the code generator, which is a
Good Thing.  (Incidentally, this is what the CPR analysis is all about -
identifying places where a Constructed Product is Returned.)

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080104/8d840154/attachment.bin