#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Concerning the patch, I just looked at the `CoreSyn` changes in https://github.com/scpmw/ghc/commit/d829a088a98b1d716ad4d51593d22deae0e97d0a. I think it's a real improvement. I've left a couple of notes about `Ord` instances, which I hate. I still find the language that specifies what "placement" or "scoping" is, hard to understand. I'd urge you to add a list of all the transformations you can think of, in a table, with their placement/scoping properties. Something like this: {{{ Transformation Before After Placement Scoping ---------------------------------------------------------------- tick t (\x.e) \x.tick t e PlaceNonLam n/a tick t (let x = e in b) let x = e in tick t b --- never -- tick t (let x = e in b) let x = tick t e in tick t b n/a Soft (tick t fun) arg tick t (fun arg) ...etc... ...etc... }}} That would bring focus to the general descriptions. There should pretty be a line of the table for each call that makes use of the properties to allow, or disallow, a transformation. Oh, maybe you need a column for "counts" which is (I believe) a third property of a tick that, with scoped/placement, says which transformations are valid. Maybe you want a third data type rather than a boolean, to highlight this fact? Some comments with `tickishScoped` would be useful. Why are HPC ticks `NoScope`? That sounds as though we can move code outside an HPC tick so it is no longer covered. Or something. As the the wiki page, there is stuff that you take for granted but which forms the big picture * The fact that semantically ticks never have significance. * What it means for a tick to "cover" some code. * The fact that (I think that) ticks have lexical scope, from the point of view of what it means to be "covered". * A little summary of the various kinds of ticks, their significance and a rough sketch of how they work. For example, your new `SourceNotes` turn into something attached to DWARF records which is somehow recovered by a debugger. It's hard to get from the `SourceNote` data constructor to all that relevant other stuff in the compiler. Of course you can put all this big-picture stuff in `CoreSyn` with the data type declarations, but it's getting big. Maybe you want a module for the `Tick` stuff that `CoreSyn` imports, where we can accumulate this overview material. Broadly speaking, though, it looks fine to me. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3693#comment:69 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler