| Thanks. Sorry if I'm being a bit dim, but could you tell me if ghc | will optimise out the boxed tuple construction in both these cases? It depends if the "..." is strict in 'p' or 'q'. If not, no it won't get optimised away, and rightly so. Exmape f x = let (p,q) = case h x of (# p,q #) -> (p,q) in (q,p) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Adrian Hey | Sent: 07 February 2005 13:03 | To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org | Subject: Re: Unboxed Tuples | | On Monday 07 Feb 2005 9:28 am, Simon Peyton-Jones wrote: | > Good point. Yes you can rely on it; but the binding is lazy. So for | > this | > | > h :: Int -> (# String, String #) | > h = ... | > | > | > f x = let (# p,q #) = h x in ... | > | > you'll get | > | > f x = let (p,q) = case h x of (# p,q #) -> (p,q) | > in ... | > | > So the call to h only happens when either p or q is used. | > | > On the other hand, if any of the binders in a let-pattern has an | > unlifted type (e.g. Int#) then the whole pattern match becomes strict. | > So if p or q had an unlifted type, the match would be strict. | > | > I'll add a note to the usre manual. | | Thanks. Sorry if I'm being a bit dim, but could you tell me if ghc | will optimise out the boxed tuple construction in both these cases? | | I guess the answer must be yes in the second case because AFAIK | you can't build an ordinary tuple containing an Int#. (But maybe | I'm wrong.) | | Regards | -- | Adrian Hey | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users