On Fri, Oct 3, 2008 at 7:26 PM, Tim Chevalier <[EMAIL PROTECTED]> wrote: > On Fri, Oct 3, 2008 at 2:29 PM, Jason Dusek <[EMAIL PROTECTED]> wrote: >> Lennart Augustsson <[EMAIL PROTECTED]> wrote: >>> But (a) is not a lifted version of a, whereas (a,b) is a lifted >>> version of the a b product. >>> So it's not consistent, and thereby wrong. >> >> Well, we can't represent the unlifted product in Haskell, >> right? You have to use some constructor. So if we just say we >> are using tuples to represent unlifted products, what's so bad >> about that? >> > > Unless I'm confused, unboxed tuples represent unlifted products. In a > sense this is "[using] some constructor", but in a sense not, since an > unboxed tuple constructor has no runtime representation.
Well, unboxed tuples are not really lifted nor unlifed, since you can't even pass one to a function. I like to pretend tuples are unlifted. Here's how I do it: * Never use seq on tuples (or functions). I could make this precise by putting seq in a typeclass (like it used to be - like it should be), and not having instances for tuples. * Never do a strict pattern match on a tuple. I.e. instead of writing f (x,y) = ..., I will write f ~(x,y) =... everywhere. Then (_|_,_|_) might as well be _|_, we have no way to tell them apart. I like to pretend functions are unlifed the same way; i.e. const _|_ = _|_. There are apparently occasions where lazily matching on a tuple will introduce a space leak. I am not 1337 enough to recognize them yet. Luke _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe