On 08 November 2005 12:09, Rene de Visser wrote:
One idea that occurred to us recently is this: GHCi could provide a simplified version of the cost-centre-stack machinery *all the time*,
Simon
This still doesn't explain to me why
C:\Haskell\dev>main +RTS -xc
gave
main: Error in array index (This is with full profiling turned on)
This sort of stack is not going to help anyone.
Hmm yes, this is indeed rather unhelpful. I can explain why it happens, though. The compiler has lifted out the error case into a top-level binding: x = error "Error in array index" and the profiling system takes the view that any costs involved in evaluating a CAF to head normal form should not be attributed to any particular call site in particular, because the call site that gets to evaluate the CAF first can change as a result of strictness analysis or other optimisations, and it isn't useful to expose this kind of non-determinism to the programmer. So the cost center stack when evaluating a CAF is always rooted at the CAF itself, and ignores the call site. CAFs are the free variables of the program, if you like. This is the argument, however I'm not sure I buy it any more. It clearly isn't very useful for backtracing, for one thing. It wouldn't really do any harm to have the costs for a CAF grafted onto the call stack at the site of its first evaluation. Figuring out how to make cost-centre-stacks do the right thing with CAFs is something of an open problem, in fact; there are currently cases where GHC produces strange results. Things get hairy when CAFs get evaluated to data structures that contain functions (eg. dictionaries). Cheers, Simon