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 <simo...@microsoft.com> wrote: > | 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
