Unlifted data types
dan.doel at gmail.com
Mon Sep 7 23:09:18 UTC 2015
On Mon, Sep 7, 2015 at 5:37 PM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> But it's an orthogonal proposal. What you say is already true of Array# and IORef#. Perhaps there are functions that are usefully polymorphic over boxed-but-unlifted things. But our users have not been crying out for this polymorphism despite the existence of a menagerie of existing such types, including Array# and IORef#
Well, evidently people over in the ArrayArray thread want it, for one.
But also, if general unlifted types get accepted, there are many
possible uses. For instance, people working with concurrency have to
worry about work being done in the correct thread, and there are
functions on MVars and whatnot that ensure that threads don't simply
pass thunks between each other. But, if you have unlifted types, then
you can have:
data UMVar (a :: Unlifted)
and then the type rules out the possibility of passing thunks through
a reference (at least at the top level). But this requires
polymorphism to avoid having to create a separate type for each
This is also a use case of `Force`, since it is likely that we want to
put ordinary data types in the MVars, just ensure that we aren't
passing thunks with delayed work.
I'm kind of down on being polymorphic over choice of evaluation order,
as well. At least without any further motivation.
Also, I'd still like to synthesize some of the redundancies introduced
by the proposal. Perhaps it could be done by making `Force` a more
primitive building block than !. I.E.
data Nat = Zero | Suc !Nat
can be, under this proposal, considered sugar for something like:
data Nat = Zero | Suc_INTERNAL# (Force Nat)
pattern Suc x = Suc_INTERNAL# (Force x)
and all stipulations about what you can UNPACK are actually about
Unlifted fields, rather than ! fields (which just inherit them from
That still leaves `Force LiftedSum` vs. `UnliftedSum`, though. And to
be honest, I'm not sure we need arbitrary data types in Unlifted;
Force (which would be primitive) might be enough.
More information about the ghc-devs