#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 simonmar): *Please* do not do this in base, instead provide a separate package that 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. We should be deeply suspicious about hard-wiring a particular debugging method into the types of core library functions. It just seems entirely wrong. Useful perhaps, but wrong. Let's not forget we have no less than 3 ways to get call stacks, each with advantages and disadvantages: * Profiling * Execution stacks (DWARF) * Implicit call stacks None of these is perfect, where perfect is something like: full call stacks available all the time with no changes to the source code, no performance overhead, and no need to recompile. Each method compromises on one or more of these things. Implicit call stacks are great for finding out where you called 'error' from, but they don't scale up to solve the general problem. We start to need multiple versions of functions, and RULES and magic in Haddock to hide this mess from users. In contrast, you can just compile everything with profiling and get full call stacks, or you can use execution stacks which probably provide enough information in most cases. Neither of these things requires any source-level changes. That's why I think we should stop where we are with implicit call stacks. 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11035#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler