Floated error expressions get poor strictness, leaving bad arity
GHC is careful to ensure that
f = \x. case x of
[] -> error "urk"
(y:ys) -> \z. <blah>
gets arity 2. It does this by giving error
an infinite arity. But if the error call is floated out by full laziness thus
lvl = error "urk"
f = \x. case x of
[] -> lvl
(y:ys) -> \z. <blah>
it's a bit less obvious. But it's ok: the strictness analyser disovers that lvl
diverges.
Alas, if f
is marked INLINE, there's a danger that this does not happen properly, perhaps because the inlining happens after strictness analysis. Or because the error message involves the parameter:
{-# INLINE f #-}
f = \x. case x of
[] -> error ("urk" ++ x)
(y:ys) -> \z. <blah>
I think I've seen this in connection with array indexing (where the error case is the index out of bounds error). I'm recording this ticket so that I don't forget about this problem.
Trac metadata
Trac field | Value |
---|---|
Version | 6.10.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |