Re: Using GHC API to compile Haskell file

> Sorry about the delay; I hadn't gotten around to seeing if I could reproduce > it. Here is a working copy of the program which appears to work with GHC > 7.10.2 on 64-bit Windows: Thanks, that does indeed solve it the first bit. To try and make it a bit clearer what I'm after, I've put the

Re: Unlifted data types

Another good example would be foo :: ![Int] -> ![Int] Does this force just the first constructor or the whole spine? My guess would be the latter. On Fri, Sep 4, 2015, at 08:43, Edward Z. Yang wrote: > Excerpts from Eric Seidel's message of 2015-09-04 08:29:59 -0700: > > You mention NFData in

Re: Unlifted data types

All your examples are non-recursive types. So, if I have: data Nat = Zero | Suc Nat what is !Nat? Does it just have the outer-most part unlifted? Is the intention to make the !a in data type declarations first-class, so that when we say: data Nat = Zero | Suc !Nat the !Nat part is now

Re: Unlifted data types

Excerpts from Edward Z. Yang's message of 2015-09-04 08:43:48 -0700: > Yes. Actually, you have a good point that we'd like to have functions > 'force :: Int -> !Int' and 'suspend :: !Int -> Int'. Unfortunately, we > can't generate 'Coercible' instances for these types unless Coercible becomes >

Re: Unlifted data types

Excerpts from Eric Seidel's message of 2015-09-04 08:29:59 -0700: > You mention NFData in the motivation but then say that !Maybe !Int is > not allowed. This leads me to wonder what the semantics of > > foo :: !Maybe Int -> !Maybe Int > foo x = x > > bar = foo (Just undefined) > > are.

Re: Unlifted data types

Hello Eric, You can't tell; the head not withstanding, `[a]` is still a lazy list, so you would need to look at the function body to see if any extra forcing goes on. `Force` does not induce `seq`ing: it is an obligation for the call-site. (Added it to the FAQ). Edward Excerpts from Eric

Re: Unlifted data types

Excerpts from Dan Doel's message of 2015-09-04 09:57:42 -0700: > All your examples are non-recursive types. So, if I have: > > data Nat = Zero | Suc Nat > > what is !Nat? Does it just have the outer-most part unlifted? Just the outermost part. > Is the intention to make the !a in data type

Re: A process for reporting security-sensitive issues

I agree with Adam. I've been a little worried about users relying on Safe Haskell, despite #9562. Advertising that Safe Haskell is just a "best effort" (for a rather high bar for "best") but not a guarantee would be nice. Richard On Sep 3, 2015, at 10:50 PM, Adam Gundry

Re: Unlifted data types

Okay. That answers another question I had, which was whether MutVar# and such would go in the new kind. So now we have partial, extended natural numbers: data PNat :: * where PZero :: PNat PSuc :: PNat -> PNat A flat domain of natural numbers: data FNat :: * where

Re: Unlifted data types

Excerpts from Dan Doel's message of 2015-09-04 13:09:26 -0700: > Okay. That answers another question I had, which was whether MutVar# > and such would go in the new kind. > > So now we have partial, extended natural numbers: > > data PNat :: * where > PZero :: PNat > PSuc :: PNat

Re: question about GHC API on GHC plugin

Hi Mike, I'll try to hack an example for you some time tomorrow(I'm returning from ICFP and have some long flights ahead of me). But in the meantime, here's a working Core code, generated by GHC: f_rjH :: forall a_alz. Ord a_alz => a_alz -> Bool f_rjH = \ (@ a_aCH) ($dOrd_aCI ::

Re: question about GHC API on GHC plugin

Typo: "You're parsing your code" I mean "You're passing your code" 2015-09-05 0:16 GMT-04:00 Ömer Sinan Ağacan : > Hi Mike, > > I'll try to hack an example for you some time tomorrow(I'm returning from ICFP > and have some long flights ahead of me). > > But in the meantime,

Re: Unlifted data types

Excerpts from Dan Doel's message of 2015-09-04 14:48:49 -0700: > I don't really understand what this example is showing. I don't think > SPair is a legal > declaration in any scenario. > > - In current Haskell it's illegal; you can only put ! directly on fields > - If !a :: Unlifted, then (,)

Re: Unlifted data types

On 05/09/15 00:41, Roman Cheplyaka wrote: > On 05/09/15 00:23, Edward Z. Yang wrote: >> I would certainly agree that in terms of the data that is representable, >> there is not much difference; but there is a lot of difference for the >> client between Force and a strict field. If I write: >> >>

Re: question about GHC API on GHC plugin

I'm still having trouble creating Core code that can extract superclass dictionaries from a given dictionary. I suspect the problem is that I don't actually understand what the Core code to do this is supposed to look like. I keep getting the errors mentioned above when I try what I think should

Re: Unlifted data types

Here are some additional thoughts. If we examine an analogue of some of your examples: data MutVar a = MV (MutVar# RealWorld a) main = do let mv# = undefined let mv = MV mv# putStrLn "Okay." The above is illegal. Instead we _must_ write: let !mv# = undefined

Re: Unlifted data types

On 05/09/15 00:23, Edward Z. Yang wrote: > I would certainly agree that in terms of the data that is representable, > there is not much difference; but there is a lot of difference for the > client between Force and a strict field. If I write: > > let x = undefined > y = Strict x >

Re: Unlifted data types

If x :: t, and t :: Unlifted, then let x = e in e' has a value that depends on evaluating e regardless of its use in e' (or other things in the let, if they exist). It would be like writing let !x = e in e' today. -- Dan On Fri, Sep 4, 2015 at 5:41 PM, Roman Cheplyaka

Re: Unlifted data types

On Fri, Sep 4, 2015 at 5:23 PM, Edward Z. Yang wrote: > But this kind of special handling is a bit bothersome. Consider: > > data SPair a b = SPair (!a, !b) > > The constructor has what type? Probably > > SPair :: (Force a, Force b) -> SPair a > > and not: > > SPair

Re: Foreign calls and periodic alarm signals

> a good start would be to open a ticket. Okay, done: https://ghc.haskell.org/trac/ghc/ticket/10840 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Unlifted data types

Hello friends, After many discussions and beers at ICFP, I've written up my current best understanding of the unlifted data types proposal: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes Many thanks to Richard, Iavor, Ryan, Simon, Duncan, George, Paul, Edward Kmett, and any others