#1592: Unexpected boxing in generated code
-------------------------+--------------------------------------------------
Reporter: neil | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.6.1
Severity: minor | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
-------------------------+--------------------------------------------------
Comment (by simonpj):
Simon M responds: exitWith in fact doesn't exit: it raises the exit
exception, which is caught by the top-level exception handler, which
finally arranges to exit. So I imagine the strictness analyser inferred
that exitWith returns
bottom, and hence it was justified in evaluating len first.
This doesn't seem specific to exit, to me. Throwing any exception would
trigger this behaviour. Indeed, since we're in the IO monad, I might
reasonably expect to have greater control over the evaluation order, and
perhaps GHC is right - the strictness analyser should not cause something
to be evaluated earlier than normal if that means moving it past a
possible
effect. In fact this behaviour seems to be essential if we are to be able
to use lazy I/O in a sensible way, because otherwise lazy I/O can be
evaluated earlier than we expect:
{{{
do
s <- getContents
putStr "prompt:"; hFlush stdout
case s of ...
}}}
We are sure to evaluate s, but we better not do it before the `putStr`
(I'm
sure the strictness analyser won't do this right now, because it won't
infer that putStr returns, but imagine some simpler IO instead).
I'm not quite sure what to make of this. On the one hand it's ugly,
because we're forced into an evaluation order. But even if it weren't for
lazy I/O, I am tempted to think that the IO monad ought to restrict
evaluation order, if only so that we can have more control when we want
it.
So perhaps GHC is doing the right thing.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1592>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
