Opened 10 years ago

Closed 5 years ago

#1509 closed feature request (fixed)

Make unboxed tuples more supported

Reported by: guest Owned by:
Priority: low Milestone:
Component: Compiler Version: 6.6.1
Keywords: Cc: ndmitchell@…, id@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Unboxed tuples (# a, b #) do not have the same features as boxed tuples ( a, b ). In particular:

1) There is no prefix form, (#,#) a b is not equivalent to (# a, b #). We would have to define a collection of such functions in the Prelude (see Data.Tuple, for the () functions). We'd have to do is to make the parser understand (#,,,#).

2) Currently GHC does not allow f :: (# a, b #) -> ..., but there's no real reason why not; GHC could transform them away just before code generation.

Change History (8)

comment:1 Changed 10 years ago by Isaac Dupree

Cc: id@… added

(See <> thread.)

I was realizing that I had a use where a group of function arguments had to be a single type, but I didn't want to introduce an extra possible _|_ via a normal boxed tuple. Not sure it would have actually been possible to use an unboxed type there, but it would be nice if this part of it worked. (possibly some type-level ! strictness annotations would be good for that purpose instead)

comment:2 Changed 10 years ago by Isaac Dupree

Adding prefix-unboxed-tuples turned out to just require a parser modification -- for GHC at least, Data.Tuple only defines data types and constructors (and Eq,Ord... instances) of (boxed) tuples; unboxed tuples were already built-in, (or anyway my test passed and ran successfully after a simple parser addition). see darcs patches on cvs-ghc list.

comment:3 Changed 10 years ago by simonpj

Note: current unboxed tuples are eta-expanded by CorePrep since Id.hasNoBinding returns True. So we don't need to worry about generating curried versions of them. Nor would be possible to do so, since unboxed tuples can have unboxed components of varying width; they are not parametrically polymorphic.

See also Note [Primop wrappers] in Id.lhs.


comment:4 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:5 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:6 Changed 5 years ago by morabbin

Type of failure: None/Unknown

Bump; still relevant?

comment:7 Changed 5 years ago by thoughtpolice

Max Bolingbroke fixed issue 2 about a year ago in a set of changes he made to handling unboxed tuples. They're now supported in function arguments, variables and type constructors.

I don't think issue 1 has been addressed, but I'm not sure how relevant it still is.

comment:8 Changed 5 years ago by simonmar

Resolution: fixed
Status: newclosed

Let's call it fixed.

Note: See TracTickets for help on using tickets.