- ghc-devs - Haskell.org

Kind equalities update
by Richard Eisenberg 14 Oct '15

14 Oct '15

Hi devs, In a chat with Simon this morning about kind equalities, he expressed that you all might want to know about the plans for kind equalities in 8.0. The wiki page both for user-facing changes and for implementation notes is here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 It is my intent that all user-facing changes mentioned there will be available in 8.0. I am hard at work getting my branch ready to merge, and hope to do so mid-November. Note: this is almost fully backward-compatible. Here are some areas where there are known incompatibilities: - Template Haskell will have to be updated. But there's a raft of changes there, anyway. - GHC will do a more careful job of checking for termination of instances regarding the use of kind variables. This may require new UndecidableInstances declarations. But the fact that these definitions (like `instance (C a, C b) => C (a b)` for a polykinded C) were accepted previously could be called a bug. That's actually all I know of so far. You can take kind equalities for a spin at github.com/goldfirere/ghc, on the "nokinds" branch. Note that this hasn't been merged with `master` since December of last year, so expect a little strange behavior compared with 7.10. These wrinkles will get smoothed out, of course. Richard

5 6

Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args
by Christiaan Baaij 14 Oct '15

14 Oct '15

Hi, As a GHC API user, I would like to run GHC’s strictness and demand analysis pass, but I don’t want any worker/wrappers. My specific use-case is to generate digital circuits from Haskell code, where I’ve yet to encounter any benefit from worker/wrappers: the generated circuits do not get any smaller or faster. They do however induce longer compilation times for my compiler. I still want to have GHC’s strictness and demand analysis, because, if I understand correctly, the demand and strictness annotations are needed by GHC’s dead code analysis (and other optimisations) which is beneficial for my use case. Looking through DynFlags, I encountered the ‘maxWorkerArgs’ field, which is controlled by ‘-fmax-worker-args’. The user guide says the following: "If a worker has that many arguments, none will be unpacked anymore (default: 10)” I don’t know exactly what this means, but I was hoping that if I would set that number to 0 (zero), no worker/wrapper pairs would be created. Is that correct? The reason that I’m asking is because -fmax-worker-args is basically dead code. The ‘maxWorkerArgs’ field of DynFlags is not used anywhere. If setting ‘-fmax-worker-args’ to zero does indeed prevent any worker/wrappers from being generated, should I reimplement the flag and submit it as a patch? Or, is it preferable to simply remove ‘-fmax-worker-args’ (given that it doesn’t do anything right now), and create a new flag, ‘-fno-worker-wrapper’, that simply disables the creation of worker/wrapper pairs everywhere? Regards, Christiaan

2 1

HEADS UP: HCAR due at the end of this month
by Austin Seipp 13 Oct '15

13 Oct '15

Hi *, The November edition of the HCAR is soon, so it's that time of the year again! https://ghc.haskell.org/trac/ghc/wiki/Status/Oct15 I've gone ahead and taken most of the basic info directly from the 8.0.1 status page. Everyone, please take 5 minutes to read over this page and make sure whatever you want mentioned is there. Remember: this is *not* the status report for 8.0 necessarily - so if you have something planned after 8.0 that you're working on, go ahead and add it! I'll be touching up the markup etc to bring it in line with what we usually have (bold highlights, etc). In the mean time, just write your blurb - I'll do the wordsmithing for the final draft... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

(Don't) remove unused flags? [#10935]
by Alexander Berntsen 10 Oct '15

10 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I want to tackle [0], but I disagree with the proposed solution. At least with regards to the first three flags. Instead, I want to make the flags work. Thoughts? [0] <https://ghc.haskell.org/trac/ghc/ticket/10935> - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWGO9CAAoJENQqWdRUGk8BUiMP/1PfMfXr4p1jWCasPHvWMrXj Ep0/e5boThJs3bsD+xf1eVl2NIjT4dAONO7zI7PkohvkjbgjXGWFE+SDJKI6iWXV Kb06GM73q7vBL3sL45SFy8/tofn0J//jSAkXoNzJ64Nlny2xXxLg91e0mj79fbGx Y3rwv7SB9ZpBm/ov41PtiX5+5hc3mWDwZS/+UIUj1tUdfFHk8BR4HMEXEfihU0mh yrxdPHWsAYmIPYfoE/9HAbQ6SqynUErW8kOrr47/kZO0yBl2xkK7XvA7I0fy0upG HS6teTcxtVmzFFPBrDvZGEz0cawT56/jpMBNHNgkLUOF3lssjLpMCl3KyoJXV9PB kaHxICISubBsLoIZti/MQBshjwbLzT6MCItMIlD77w21mp3MEqiFQ9+M+ePCwGp8 WmX5iAFc8ze6bku51cYGSxiIjIMcpJVNI4Sr+8aRFuFBUqiOe/GKn0t5UvyPMekb FTcYLH4JKjBEXkkuF2WWr+Ey+d87XQ1ioN+wwg+v2pFGP4NtwepoNbYsQG4WbHYx gFAdWAnirsdSrio5VTZWVz05ouIIUG6CtDM6QfaC3EUCLDWePz+fd63U+gjO3A4s AW8Rfm/rDQBNs7USIgODjKdDtGwAJM4i+PxypWW8rg9sfOBwGEcS8XngphxWb6pp bHkPHy6k+vGOrZUUSMFb =B8HY -----END PGP SIGNATURE-----

1 0

Template Haskell bikeshedding: UnboundVarE or not?
by Richard Eisenberg 10 Oct '15

10 Oct '15

Hi devs, Jan Stolarek has been hard at work allowing Template Haskell to deal with holes in expressions. Thanks, Janek. In this patch, any unbound variable is treated like a hole, which is exactly the way that GHC normally treats unbound variables these days. This is great -- it allows TH quotes to work with unbound names. The question is this: suppose a user writes [| x |], where x is unbound. Should that produce a (VarE (mkName "x")) or an (UnboundVarE (mkName "x")), where UnboundVarE is a new constructor for Exp? Reasons for UnboundVarE: - It communicates information GHC has to clients of TH. Reasons against UnboundVarE: - UnboundVarE and VarE are treated identically in *splices*. The only point of UnboundVarE is in the output of *quotes*. This may be confusing to users. - The information communicated by GHC to TH can be gotten by other means. Specifically, if you try to `reify` an unbound name, you'll get an error (which can be caught gracefully). Bound names `reify` correctly. So a TH client can figure out the boundedness of a variable, albeit awkwardly and in a monad. This counts as a reason against UnboundVarE because the distinction between UnboundVarE and VarE is technically redundant. (You could also probably learn this information by looking to see if a Name has a Unique attached to it. But that's a bit dirty. At least it's pure, though.) So, what do you think? To UnboundVarE or not to UnboundVarE, that is the question. Ticket: https://ghc.haskell.org/trac/ghc/ticket/10267 Diff: https://phabricator.haskell.org/D835 Thanks! Richard

3 2

Floating and CorePrep
by Simon Peyton Jones 08 Oct '15

08 Oct '15

Luke asks | Also, can you explain why CorePrep does some floating of its own? I thought that there was a good reason that CorePrep does floating, but the more I tried to explain it, the less sense the explanation made. So here's the reasoning. Maybe I'm missing things, or maybe there's an opportunity here to simplify GHC. So I'm cc'ing ghc-devs. CorePrep convets to ANF. So if we have this: x = f (g y) we might naively generate this x = let a = g y in f a Instead CorePrep generates this a = g y x = f a However now I think about it again, I'm suddenly not sure why this is important. * If x is a lazy thunk, the floated version will allocate 'a' early. So we should only float if (f a) is a head-normal form. (And that happens; see CorePrep.wantFloatNested). But if (f a) is a HNF, the simplifier will already have ANF'd it in prepareRhs. * If x is marked demanded (strict), then the naive ANF'ing might generate case (let a = g y in f a) of .... because CorePrep converts the 'let x' into a case. But that's OK because I think the code generator is fine with a let nested inside a case like that. So, for nested bindings, maybe we can simply NEVER do floating? Ah, there is on gotcha. Consider x = f raise# where f has arity 2. Currently raise# responds True to Id.hasNoBinding, so CorePrep must eta-expand to x = f (\x. raise# x) and now we really would like to ANF to z = \x. raise# x x = f a because the (f a) is not a thunk, but it would be if we introduced a nested let. Bother. For top level, things are slightly different. Here if we see x = f (g y) we do want to float to get a = g y x = f a because not the allocation of 'a' is done statically rather than dynamically. This is particularly important for large static lists e.g. p = f [a,b,c,d,e] when we want all those cons cells to be statically allocated. This is all a bit unsatisfactory. It would be much cleaner if all floating was done by the simplifier, and CorePrep did none. And I think it'd be worth a try at doing that. I think the needful stuff would be: * Always saturate hsaNoBinding functions in Core, not just at CorePrep * Be more aggressive about floating top-level bindings like 'p' in the simplifier I'm not likely to undertake this myself soon, but I could advise. Simon

1 0

ghc-7.10 branch broken
by Simon Peyton Jones 06 Oct '15

06 Oct '15

On the ghc-7.10 branch, PPC.Regs has duplicate exports (see below). The offending lines are fReg, sp, r3, r4, r27, r28, r30, r0, sp, r3, r4, r27, r28, r30, tmpReg, and indeed there are duplicates. Why? git branch -v * ghc-7.10 e22d7dc nativeGen PPC: fix > 16 bit offsets in stack handling master f17992a [behind 1397] Updaete perf numbers for 32-bit machines wip/T10527 eb66575 Use lazy substitution in simplCast wip/T10527-2 9e4908b Add an ambient Id substitution to Subst Simon compiler/nativeGen/PPC/Regs.hs:41:13: Warning: 'sp' is exported by 'sp' and 'sp' compiler/nativeGen/PPC/Regs.hs:41:17: Warning: 'r3' is exported by 'r3' and 'r3' compiler/nativeGen/PPC/Regs.hs:41:21: Warning: 'r4' is exported by 'r4' and 'r4'

2 1

RE: [GHC] #10928: Refine pattern synonym signatures
by Simon Peyton Jones 06 Oct '15

06 Oct '15

I'm getting 501 "Internal server error" from Trac. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of GHC | Sent: 06 October 2015 13:57 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10928: Refine pattern synonym signatures | | #10928: Refine pattern synonym signatures | -------------------------------------+---------------------------------- | -------------------------------------+--- | Reporter: mpickering | Owner: | Type: bug | Status: new | Priority: normal | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.2 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: Other | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | -------------------------------------+---------------------------------- | -------------------------------------+--- | | Comment (by rwbarton): | | One thing that bothers me about the current syntax is that `C1 a => C2 a | => T a` in general already has a meaning. It's the same thing as `(C1 a, | C2 a) => T a`. I don't know if this is actually valid Haskell 98 (I | suspect not), but GHC accepts it without any language flags. | | Just to throw out another option, long ago user "ski" on IRC suggested a | syntax for existentials-plus-constraints, dual to constrained polymorphic | values. The idea is dual to {{{ forall a. C a => T a }}} which is a sort | of function that accepts a `C a` constraint and produces a value, we have | {{{ exists a. C a *> T a }}} which is a sort of pair of a `C a` | constraint (dictionary) and a value. | (Mnemonic: `*` is like a pair and `>` is from `=>`. Not sure I am | convinced myself.) | | I'm not sure whether this applies directly to pattern synonyms since a | pattern is not really the same thing as a value. But, we could at least use | the idea of two different bits of syntax for provided and required | constraints, e.g., {{{ pattern P :: (Eq a, Num a) => (Show a, Show b) *> b | -> T a }}} Here I am thinking of `(Eq a, Num a)` as in negative position | and `(Show a, Show b)` in positive position, so tentatively using the | corresponding `=>` and `*>`. | | Advantages: | | * Does not use syntax that already has another meaning (`C1 a => C2 a => T | a`) | | * You can write patterns with either empty required constraints or empty | provided constraints (`Cr a => T a`, `Cp a *> T a`) without having to add | an empty context | | * Not extremely verbose like Richard's verbose syntax | | Disadvantages: | | * Another funny bit of syntax to learn. But at least it appears in only | one context. | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell | .org%2ftrac%2fghc%2fticket%2f10928%23comment%3a9&data=01%7c01%7csimonpj%4006 | 4d.mgd.microsoft.com%7c36aef97285934ba72df008d2ce4ded93%7c72f988bf86f141af91 | ab2d7cd011db47%7c1&sdata=ppvz43W510K87Zo073GgRRNtUyhCv%2foAVTOKmQoFl%2b0%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell | .org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c36aef9728593 | 4ba72df008d2ce4ded93%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uSFUfOAOr% | 2b8rRO%2f3mfxurv7Xd%2bRrqvwcZFBYF0SZITc%3d> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c36aef97285934ba72d | f008d2ce4ded93%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=T8hBjZDRWulMjNrG | nrLd5TRA1cR8yEmmnuO9LfNjNG8%3d

1 0

Re: [Haskell-cafe] A GC'd heap using weak pointers
by Sumit Sahrawat, Maths & Computing, IIT (BHU) 06 Oct '15

06 Oct '15

This would be well recieved on ghc-devs mailing list. Adding to cc. On 6 October 2015 at 15:55, Thomas Koster <tkoster(a)gmail.com> wrote: > Good afternoon list, > > I am implementing a simple, interpreted language that needs a garbage- > collected heap for storage. Like most discussions on memory management, > I use the term "heap" by analogy - the actual data structure is not > necessarily a true heap. > > My Heap type is basically a map of "addresses" (Int) to values. Values > may themselves contain addresses, perhaps recursively to each other > (like letrec). The extra field in Heap stores the next unused address, > used to allocate fresh slots, as you can see in "heapAlloc". > > > type Address = Int > > data Value = ...things with Addresses... > > data Heap = Heap !Address (Map Address Value) > > > > heapAlloc :: Heap -> (Address, Heap) > > heapAlloc (Heap nextFreeAddr binds) = > > (nextFreeAddr, Heap (succ nextFreeAddr) binds) > > There is also a stack of roots and an expression under evaluation. > > > type Stack = [...things with Addresses...] > > data Expr = ...things with Addresses... > > The function I need to write is: > > > heapGC :: [Address] -> Heap -> Heap > > heapGC roots heap = ...collect unreachable values from heap... > > Rather than re-invent this particularly complex wheel, I am wondering > if I could use GHC weak pointers and have the GHC runtime collect values > in my heap for me. Something like this: > > > type Address = Int > > data Reference = Reference Address > > data Value = ...things with References... > > data Heap = Heap !Address (Map Address (Weak Value)) > > > > heapAlloc :: Heap -> (Reference, Heap) > > heapAlloc (Heap nextFreeAddr binds) = > > (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds) > > > > heapStore :: Reference -> Value -> Heap -> IO Heap > > heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do > > weakVal <- mkWeak ref val Nothing > > return $ Heap nextFreeAddr (Map.insert addr weakVal binds) > > Note the new type, Reference. This replaces Address everywhere except > in the heap's internal structure, which continues to use Address. > Reference values are opaque, unique and obtained from the heap using > heapAlloc. > > The idea is that only two things should cause Values to stay alive: > 1. reachable holders of Reference (by GHC's definition of "reachable"), > 2. ordinary Haskell closures arising from stepping the interpreter. > "Being in the Heap" should not be enough to keep a Value alive. Then, > my heapGC function should only have to prune dead addresses from the > map. > > I am having trouble getting a proof-of-concept working (I am unable to > observe any finalizers running, ever), but before I get into that, is > this idea sound? Has somebody else implemented this in a library > already? > > Thanks, > Thomas Koster > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat

1 0

Re: Generic instances for GHC AST
by Ryan Scott 05 Oct '15

05 Oct '15

> If the unboxed types are a problem for the automatic Generic derivation, a > manual instance could be written instead. As of recently [1], -XDeriveGeneric should be capable of handing unboxed types, so that removes one major technical limitation. I'm not sure which unboxed types GHC's API uses off of the top of my head, but if you need something other than Addr#, Char#, Double#, Int#, or Word#, it wouldn't be too difficult to add support for them. Ryan S. ----- [1] https://git.haskell.org/ghc.git/commit/6cde981a8788b225819be28659caddc35b77…

2 1