I have put up an alternate set of proposals on
https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes
These sidestep around `Force` and `suspend` but probably have other problems. They make heavy use of levity polymorphism.
Back story: this all was developed in a late-evening Haskell Symposium session that took place in the hotel bar. It seems Edward and I walked away with quite different understandings of what had taken place. I've written up my understanding. Most likely, the Right Idea is a combination of this all!
See what you think.
Thanks!
Richard
On Sep 8, 2015, at 3:52 AM, Simon Peyton Jones
| And to | be honest, I'm not sure we need arbitrary data types in Unlifted; | Force (which would be primitive) might be enough.
That's an interesting thought. But presumably you'd have to use 'suspend' (a terrible name) a lot:
type StrictList a = Force (StrictList' a) data StrictList' a = Nil | Cons !a (StrictList a)
mapStrict :: (a -> b) -> StrictList a -> StrictList b mapStrict f xs = mapStrict' f (suspend xs)
mapStrict' :: (a -> b) -> StrictList' a -> StrictList' b mapStrict' f Nil = Nil mapStrict' f (Cons x xs) = Cons (f x) (mapStrict f xs)
That doesn't look terribly convenient.
| 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).
Really? Presumably UMVar is a new primitive? With a family of operations like MVar? If so can't we just define newtype UMVar a = UMV (MVar a) putUMVar :: UMVar a -> a -> IO () putUMVar (UMVar v) x = x `seq` putMVar v x
I don't see Force helping here.
Simon _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs