October 2015 - ghc-devs

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

Pattern Synonym Signature Confusion
by Matthew Pickering 03 Oct '15

03 Oct '15

I think that the current state of pattern synonym signatures is quite confusing, especially regarding the constraints. For those unfamiliar, a signature looks like the following, pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a The first constraint being the "provided constraints" and the second the "required constraints". My main concern is when only a single constraint is specified then these are treated as the provided constraints. The manual gives the reason that this is the "more common" choice. It seems that this motivation is driven by the original ticket which had a lengthy discussion about GADTs. In my experience, the opposite is true, it is more common to have required constraints. This is true especially in a few common cases such as "pattern Foo = 27", where users define pattern synonyms which have (overloaded) literals on the RHS. The most general signature for such a pattern is "pattern :: () => (Eq a, Num a) => a". For this reason, I think it would be better if either 1. Only specifying one constraint corresponded to the required constraints 2. We required users to specify both sets of constraints, even if the provided constraints are empty. In terms of breakage, I don't think that pattern synonym signatures are widely used yet. In both schemes it is possible to write backwards compatible code by writing both sets of constraints. I think a lot of the confusion also arises from the unusual form of the signature, it is unusual to specify two sets of constraints and I suspect users tends to assume that a single set of constraints is either provided or required depending on what they want it to mean. Forcing the specification of both, forces the user to make the distinction earlier rather than trying to decipher error messages. Thoughts? Matt

5 6

Switching users guide to ReStructuredText
by Ben Gamari 02 Oct '15

02 Oct '15

Hello friendly GHCers, Last week I sent out poll asking opinions on moving the Users' Guide From Docbook to ReStructuredText. While the response wasn't particularly large in volume, those that did reply were quite supportive of the idea. This week I took the time to clean up my hacked prototype. After quite some build system wrangling, it's finally in a merge-worthy state as D1294. You can see the output at, http://smart-cactus.org/~ben/ghc-users-guide/html/index.html http://smart-cactus.org/~ben/ghc-users-guide/users_guide.pdf In addition to converting the DocBook to ReST, this also involved ripping out the previously rather fragile system for building the `ghc` manpage and describing GHC's flags in utils/mkUserGuidePart. Feel free to look over the output. If there are no objections I'll merge this tomorrow. Future Work ----------- * Verify the flag description in mkUserGuidePart against DynFlags (checking for missing or invalid flags) * Perhaps incorporate make flags representation a bit richer, encoding, for instance, implication relationships between flags * Generate flag descriptions for bash_completion and other shells * Improve manpage content * Be more precise about which code samples should be syntax highlighted Cheers, - Ben

5 9

Status of recent DWARF work
by Ben Gamari 02 Oct '15

02 Oct '15

Hello everyone! Over the last month or so I've been working on better incorporating Peter Wortmann's DWARF work into the GHC. The immedate goals are two-fold, * Allow access to reified stacks in the RTS and user programs * Introduce some basic statistical profiling functionality into the RTS While I have been slowly writing up a more general description of the work, this work has already gone too long unannounced so I'm just going to plop the list of relevant Differentials here. Note that this is also available on the Wiki (https://ghc.haskell.org/trac/ghc/wiki/DWARF/80Status) complete with hyperlinked Diffs. The hope here is that this summary will make it easier for others to review this work. Cheers, - Ben Notation -------- These are in various states of completion which I'll encode with the following designations, * MERGED: Already merged to `master`, listed here for completeness * REVIEW: Believed to be finished with no expectation of major rework being necessary. Should be in merge-worthy condition, pending code review. * RFC: Code done, builds, and tested to some extent; needs design review. * EXPLOR: Exploratory work, may not even build but included to document the expected future direction of the work. * IDEA: Just an idea, no implementation yet. I'll list the commits in the order of their logical progression, The Patches ----------- These preparatory commits address a few bugs and deficiencies in the current DWARF production implementation, * [MERGED] Phab:D1172 Dwarf: Fix DW_AT_use_UTF8 attribute * [MERGED] Phab:D1173 Dwarf: Produce {low,high}_pc attributes for compilation units * [MERGED] Phab:D1174 Dwarf: Produce .dwarf_aranges section * [MERGED] Phab:D1220 Dwarf: Ensure block length is encoded correctly These introduce DWARF parsing and stack unwinding to the RTS by introducing an optional dependency on `libdw`. This is the same library used by `perf`. * [REVIEW] Phab:D1196: Libdw: Add libdw-based stack unwinding * [REVIEW] Phab:D1197: Signals: Print backtrace on SIGUSR2 With the RTS groundwork in place we can plumb things in for use by user programs, * [REVIEW] Phab:D1198: Provide DWARF-based backtraces to Haskell-land Unfortunately up until this point we have no ability to unwind out of Haskell code back to the C stack. These commits introduce the ability to unwind all the way back to `_start`, * [REVIEW] Phab:D1224: Dwarf: Preserve stack pointer register * [REVIEW] Phab:D1225: cmm: Expose machine's stack pointer and return address registers * [REVIEW] Phab:D1223: StgStartup: Add DWARF unwinding annotations for stg_stop_thread This should be enough to get reasonable backtraces for error-handling and reporting. However, we also want profiling. For this, however, DWARF annotations alone aren't sufficient. The plan here is to incorporate a more details From the source notes produced by GHC into the DWARF vendor extension DIEs. The RTS then takes these DIEs during program initialiation and emits a representation of them to the eventlog for later use by analysis code, * [RFC] Phab:D1279: Output source notes in extended DWARF DIEs * [RFC] Phab:D1280: rts: Emit debug information about program to event log * [REVIEW] Phab:D1281: Support multiple debug output levels Now we have everything necessary to add some basic statistical profiling. Here we collect samples from heap checks and black hole block events and emit them to the event log, * [RFC] Phab:D1215: A simple statistical profiler * [RFC] Phab:D1216: StatProfile: Heap and black-hole sampling This all appears to work and I have some rather crude analysis tools which I should really clean up a bit. Ideally someone would dust off Peter's Threadscope integration as this would make for an extremely compelling performance analysis story. I also have yet to examine the impact of profiling on performance when not enabled. In principle it should be cheap enough to compile in unconditionally (although event log support is needed) but this needs to be measured. In his prototype implementation Peter also had the lovely ability to preserve simplified Core for later examination. This would be a nice thing to have but probably won't happen for 8.0. The challenge here is recording the Core fragments without introducing enormous amounts of redundancy. * [EXPLOR] Phab:D1213: Core notes * [IDEA] Record tree of Core fragments into DWARF DIEs

1 0

Re: Switching users guide to ReStructuredText
by Ryan Scott 02 Oct '15

02 Oct '15

To be honest, I'm not sure if referring to sections by numbers is a great idea. New subsections get spliced into the users' guide quite frequently, which can cause all subsequent subsections to have their numbers incremented. As a result, section numbers could become out-of-date rather quickly. Thankfully, one thing that ReStructured Text does much better than the previous system is make the entire page hyperlinkable. It's now incredibly easy to click on the symbol to the right of any section header and get a link to that spot. Ryan S.

2 1