Opened 7 years ago

Closed 15 months 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 Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:


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 7 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 6 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 6 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 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:5 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:6 Changed 15 months ago by morabbin

  • Type of failure set to None/Unknown

Bump; still relevant?

comment:7 Changed 15 months 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 15 months ago by simonmar

  • Resolution set to fixed
  • Status changed from new to closed

Let's call it fixed.

Note: See TracTickets for help on using tickets.