Add Unlifted List type to base

data UList (a :: TYPE 'UnliftedRep) where
  UNil :: UList a
  UCons :: a -> UList a -> UList a

This would guarantee that values stored inside the list would not be thunks. It would likely live in something like GHC.List.Unlifted, since it uses GHC-specific things.

An example of something it might improve is the implementation of Control.Concurrent.QSem.QSem:

data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()]))

this could instead be:

type MVarIO = MVar# RealWorld -- type synonym for brevity

data QSem = QSem (MVarIO (Int, UList (MVarIO ()), UList (MVarIO ())))

Note that in this example the tuple inside the outermost MVarIO boxes the Int - this tuple could be represented as a datatype which ensures the unboxing on the Int.

The main idea here though is that now you can use MVar# inside of the UList.

Trac metadata

Trac field	Value
Version	8.6.2
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	libraries/base
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed milestone to %8.6.3

changed weight to 5

added Tfeature request Trac import core libraries labels

Hey Daniel: do you have any examples where the timing measurements would be improved by these changes to qsem? Or where unlifted list would be faster ? I agree that they might reduce indirections, but having concrete programs which benefit measurably from the change helps ground things. Also let’s us measure the impact

Additionally: these are all types you can workshop writing in users space. And these sorts of changes only make sense if you can make a measurable performance impact

Ticket retargeted after milestone closed

added Pnormal label

I think this might now require a CLC proposal @chessai