*Please* do not do this in base, instead provide a separate package that
#11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:12 simonmar]: people can use if they want this functionality.
I'm concerned about all the points you raise in the description. I
don't think I need to expand on them, you've done a great job of explaining the problems this leads to. So this gets a strong -1 from me, at least in base. Noted. I actually do have a separate package that exports location-aware variants of common partial functions (https://hackage.haskell.org/package /located-base), and I don't mind keeping the broader use of CallStacks out of base. I opened this ticket primarily because I'm not very satisfied with the error produced in the description: {{{ ghci> minimumBy compare [] *** Exception: Prelude.foldr1: empty list CallStack: error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List }}} This CallStack adds no value to the error (since `foldr1` is already identified as the culprit), but does add a fair bit of noise. Adding more CallStacks would make this error much more useful, but it doesn't sound like that will happen at this point. The other thing we could do is suppress CallStacks inside base. We'd still export a CallStack-enhanced `error` and `undefined`, we just wouldn't use them internally. Do you think the error message would be better without the partial CallStack, or does it seem more like a non-issue? ------------
I should also mention that I'm working on extending profiling to work with GHCi, so people using GHCi will get the benefit of full and detailed call stacks without any changes at the source level.
Is there a ticket for this? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11035#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler