Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,320
    • Issues 4,320
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 360
    • Merge Requests 360
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #5720

Closed
Open
Opened Dec 23, 2011 by Simon Peyton Jones@simonpjDeveloper

Unit unboxed tuple behaving oddly

I’ve just discovered something very peculiar with unboxed tuples in GHC.

	f2 x = (# True, False #)
	f1 x = (# True #)
	f0 x = (# #)

What types do these functions have?

	f2 :: a -> (# Bool, Bool #)
	f1 :: a -> (# Bool #)
BUT
	f0 :: a -> b -> (# b #)

I think this is stupid. It should be

	f0 :: a -> (# #)

But in fact even that type isn’t what you expect (ie the analogue of f :: a -> () ) Here are the kinds of the type constructors:

	(,,) :: * -> * -> * -> *
	(,) :: * -> * -> *
	() :: *

	(# ,, #) :: * -> * -> * -> #
	(# , #) :: *  -> * -> #
BUT
	(#  #) :: * -> #

In both respects unboxed unit tuples are behaving differently to boxed ones. This seems bonkers. I propose to fix this, but I wanted to check if anyone is relying on the current odd behaviour.

Simon

Trac metadata
Trac field Value
Version 7.2.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#5720