strictness of putChar: report incomplete?
The report does not seem to specify whether putChar _|_ is _|_ or not. (although it might be implied somewhere I didn't see) I orginally noticed this when jhc treated it as so and I considered this a bug since the argument should not be evaluated until the action is actually executed. however, it appears ghc has the same bug, or my reasoning is wrong. not only that, but hugs and ghc disagree with each other. ghc: putChar _|_ -> _|_ putStr _|_ -> valid IO () hugs: putChar _|_ -> valid IO () putStr _|_ -> valid IO () all the IO actions are bottom on execution of course. I believe the hugs behavior is correct and ghc and jhc are wrong, but there were differing opinions on #haskell. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham <john@repetae.net> writes:
ghc: putChar _|_ -> _|_ putStr _|_ -> valid IO ()
hugs: putChar _|_ -> valid IO () putStr _|_ -> valid IO ()
I think it comes down to buffering behaviour doesn't it? Should the character be evaluated when it is added to the output buffer, or when the output buffer is flushed to its destination? It would seem that ghc has an array of true unboxed characters for the buffer, whilst hugs has an array of boxed chars.
I believe the hugs behavior is correct and ghc and jhc are wrong, but there were differing opinions on #haskell.
Wouldn't that impose an unnecessarily burdensome implementation choice? If the Report is silent, then either choice would be permissible. However, I'm inclined to the view that where the Prelude refers to a primitive operation (e.g. primPutChar), that all prims are strict, since by implication they are not implementable in Haskell. Regards, Malcolm
I wrote:
ghc: putChar _|_ -> _|_
hugs: putChar _|_ -> valid IO ()
I think it comes down to buffering behaviour doesn't it?
Having reviewed the IRC logs, I see I was talking nonsense. You want to be able to store a closure for (putChar undefined) in a data structure, which seems like a perfectly reasonable thing to do. Provided the IO action is never actually run (after being retrieved from the data structure), the program really ought not to crash. I see that nhc98 and hbc agree with Hugs on this behaviour, so ghc _must_ be wrong. :-) Regards, Malcolm
On Tue, 2005-10-04 at 13:46 +0100, Malcolm Wallace wrote:
I wrote:
ghc: putChar _|_ -> _|_
hugs: putChar _|_ -> valid IO ()
I think it comes down to buffering behaviour doesn't it?
Having reviewed the IRC logs, I see I was talking nonsense.
You want to be able to store a closure for (putChar undefined) in a data structure, which seems like a perfectly reasonable thing to do. Provided the IO action is never actually run (after being retrieved from the data structure), the program really ought not to crash.
I see that nhc98 and hbc agree with Hugs on this behaviour, so ghc _must_ be wrong. :-)
Looking at GHC's library code we see that it is indeed forcing the char early: hPutChar :: Handle -> Char -> IO () hPutChar handle c = c `seq` do ... Duncan
participants (3)
-
Duncan Coutts -
John Meacham -
Malcolm Wallace