Re: Unlifted data types

I think the wiki page is imprecise when it says:

data unlifted UBool = UTrue | UFalse

Intuitively, if you have x :: UBool in scope, you are guaranteed to have UTrue or UFalse, and not bottom.

But I still can say: foo :: UBool foo = foo and now foo contains bottom. I know that any attempt to use foo will lead to its immediate evaluation, but that is not exactly the same as "not containing a bottom". Or am I missing something here? Janek Dnia wtorek, 8 września 2015, Richard Eisenberg napisał:

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 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