Proposal: Improved error message of "Error in array index"
simonmar at microsoft.com
Tue Nov 8 09:43:16 EST 2005
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*,
> This still doesn't explain to me why
> C:\Haskell\dev>main +RTS -xc
> <GHC.Arr.CAF>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
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
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).
More information about the Glasgow-haskell-users