Proposal: Improved error message of "Error in array index"

Simon Marlow 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*,
> 
>> Simon
> 
> This still doesn't explain to me why
> 
> C:\Haskell\dev>main +RTS -xc
> 
> gave
> 
> <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
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


More information about the Glasgow-haskell-users mailing list