- ghc-devs - Haskell.org

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

[GHC] #10913: deprecate and then remove -fwarn-hi-shadowing
by Chris Upshaw 28 Sep '15

28 Sep '15

It seems like we lost the code that -fwarn-hi-shadow switched during the add of hierarchical modules in 5.0. And while the hierarchical system makes the common way .hi files could get shadowed impossible, you can still get .hi file shadowing if you use the -i flag on multiple folders. Do we care? It is a potential source of very hard to find bugs, but it is also kind of a pathological case with how the modern module system works.

1 0

Status of deprecation/warning features (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Herbert Valerio Riedel 28 Sep '15

28 Sep '15

On 2015-09-28 at 04:56:13 +0200, David Feuer wrote: [...] > That's an excellent idea, and I think it makes sense to offer it at the > module level as well as the class level. Just change DEPRECATED to REMOVED > when it's actually removed. Speaking of such, has the deprecated export > proposal made any headway? As far as the in-flight library proposals are concerned, I plan to rather have hardwired specific warnings implemented in the style of the AMP warnings as it's crucial to have them available for the GHC 8.0 release to have the foundations for the migration plans in place. We can generalize those feature later-on (maybe even in time for GHC 8.0 if we're lucky). ---- As for the more general facilities the short answer is: They're stalled! Volunteers wanted! There's the specification over at - https://ghc.haskell.org/trac/ghc/wiki/Design/MethodDeprecations and there are 3 somewhat connected/related warning-feature tickets which ought to be co-designed to avoid obstructing each other (if there's any risk there). - https://ghc.haskell.org/trac/ghc/ticket/10071 - https://ghc.haskell.org/trac/ghc/ticket/2119 - https://ghc.haskell.org/trac/ghc/ticket/4879 For #10071 there's a very modest start at implementing this, which just modifies the parser but doesn't go much farther (see wip/T10071 branch) There's an old patch for #4879 which still works over at - https://phabricator.haskell.org/D638 Cheers, hvr

1 0

RE: How to get types including constraints out of TypecheckedModule
by Simon Peyton Jones 25 Sep '15

25 Sep '15

| What if I have a binder: | | (foo, bar) = (show, show) | | I can now get the polymorphic types of foo and bar respectively but | how do I'm not sure how I'm meant to zip up the monomorphic type of | `pat_rhs_ty`, i.e. the type of the whole rhs, with the polymorphic | types in `abs_exports`. | | I mean I could just match up the type variables and pull the | constraints in by hand but it just seems like there already ought to | be a way to do this somewhere? I'm sorry I don't understand the question. For the above pattern binding you'll get something like AbsBinds { abe_tvs = [a,b] abe_ev_vars = [ d1 :: Show a, d2 :: Show b ] abe_exports = [ ABE { abe_poly = foo :: forall a. Show a => a->String , abe_mono = foo_m :: a->String , abe_wrap = ... } ABE { abe_poly :: bar :: forall b. Show b => b->String abe_mono = bar_m :: b->String ... } ] abe_binds = { (foo_m, bar_m) = (show a d1, show b d2) } } Simon | | Alternatively my strategy to do this would be to build a map from | TyVar to the constraint and then going over the monomorphic types and | for each TyVar that's mentioned in the monomorphic type pull in the | relevant constraint and apply those to the monomorphic type. Does that | sound sensible at all? I have no idea how equality constraints and all | that fancy stuff are encoded so I hope that doesn't need any special | handling ;) | | > I hope this is of some help. If so, would you like to update the | > Commentary (on the GHC wiki) to add the information you wish had | been | > there in the first place? Thanks! | | Very much so, thanks :) | | I'd love to put this in the commentary somewhere but looking at | https://ghc.haskell.org/trac/ghc/wiki/Commentary I can't actually find | anywhere this would fit in and it just seems like an awefully specific | thing to put there. Maybe it would be better to improve the comments | instead for the next person that goes looking thoguth the source | trying to figure out where the types end up. | | For example the comment on AbsBinds could mention that this is where | the typechecker stores inferred constrainst or something like that. | | --Daniel

1 0

How to get types including constraints out of TypecheckedModule
by Daniel Gröber 25 Sep '15

25 Sep '15

Hi ghc-devs, I have a question and some code to ponder on for you all: In ghc-mod we have this very useful command to get the type of something in the middle of a module, i.e. not a toplevel binder. Essentially we just optain a TypecheckedModule and traverse the tm_typechecked_source and then extract the Types from that in various places. This all works nice and well but we have one problem, namely the contraints are missing from all types. Now I'm sure there's a good reason GHC doesn't keep those inline in the syntax tree but my question is how do I get them? I've created a testcase that demonstrates the problem: $ git clone https://gist.github.com/DanielG/1101b8273f945ba14184 $ cd 1101b8273f945ba14184 $ ghc -package ghc -package ghc-paths GhcTestcase.hs $ ./GhcTestcase Type: a Even though the type of the binder I'm looking at has the type `Num a => a`. --Daniel

2 2

RE: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules
by Simon Peyton Jones 24 Sep '15

24 Sep '15

Can someone fill in the regression-test test-case on the ticket? I assume there is one?? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 24 September 2015 08:51 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10487: DeriveGeneric breaks when the same data name is | used in different modules | | #10487: DeriveGeneric breaks when the same data name is used in different | modules | -------------------------------------+------------------------------------ | - | Reporter: andreas.abel | Owner: osa1 | Type: bug | Status: closed | Priority: highest | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.1 | Resolution: fixed | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | Phab:D1081 | -------------------------------------+------------------------------------ | - | Changes (by ezyang): | | * status: new => closed | * resolution: => fixed | | | Comment: | | Pushed. I assume we aren't backporting to 7.10? | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haske | ll.org%2ftrac%2fghc%2fticket%2f10487%23comment%3a19&data=01%7c01%7csimonpj | %40064d.mgd.microsoft.com%7c82714a5e33ae4f38b09908d2c4b539d7%7c72f988bf86f | 141af91ab2d7cd011db47%7c1&sdata=CtjXUTaEpVHihCDcvgifJ%2fTSw30niJxDDFsFqE3m | ykY%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haske | ll.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82714a5e | 33ae4f38b09908d2c4b539d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=76x0 | GO1GY8YfHiI7vNNS7U%2b9XTkUVU72nnq76N4V87o%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.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82714a5e33ae4f38 | b09908d2c4b539d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Y08eOOpKx37o | TYsnGW2m1pvQGW31Ssq%2fwwBPAwt3nUo%3d

2 1

RE: [GHC] #10904: C finalizer may be called on re-used memory
by Simon Peyton Jones 24 Sep '15

24 Sep '15

Is there a test case for this? "Test Case" is not filled in Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 24 September 2015 10:00 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10904: C finalizer may be called on re-used memory | | #10904: C finalizer may be called on re-used memory | -------------------------------------+------------------------------------ | - | Reporter: bherzog | Owner: | Type: bug | Status: closed | Priority: normal | Milestone: 7.10.3 | Component: Runtime System | Version: 7.4.1 | Resolution: fixed | Keywords: | Operating System: Linux | Architecture: | | Unknown/Multiple | Type of failure: Runtime crash | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | Phab:D1275 | -------------------------------------+------------------------------------ | - | Changes (by bgamari): | | * status: merge => closed | * resolution: => fixed | | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haske | ll.org%2ftrac%2fghc%2fticket%2f10904%23comment%3a7&data=01%7c01%7csimonpj% | 40064d.mgd.microsoft.com%7c1ba2f315ae0543169de308d2c4bee103%7c72f988bf86f1 | 41af91ab2d7cd011db47%7c1&sdata=eeIRaPoS4sctt6SMhBYcVhaaYe9dMFeAjWNynBCIDDE | %3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haske | ll.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c1ba2f315 | ae0543169de308d2c4bee103%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3Pzl | NvTz8yyifPsu5iDD82D5mghc9BDBUB9%2b541CttM%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.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c1ba2f315ae054316 | 9de308d2c4bee103%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7pPc9z4f3OrC | 3ZFCoItJBxNlDXH5w41tXqTTCGw06kQ%3d

1 0