I'm trying to use the interact function, but I'm having an issue with the following code:
main::IO()
main = interact test
test :: String -> String
test [] = show 0
test a = show 3
I'm using EclipseFP and taking one input it seems like there is an error. Trying to run main again leads to a:
*** Exception: <stdin>: hGetContents: illegal operation (handle is closed)
I'm not sure why this is not working, the type of test is String -> String and show is Show a => a -> String, so it seems like it should be a valid input for interact.
EDIT/UPDATE
I've tried the following and it works fine. How does the use of unlines and lines cause interact to work as expected?
main::IO()
main = interact respondPalindromes
respondPalindromes :: String -> String
respondPalindromes =
unlines .
map (\xs -> if isPal xs then "palindrome" else "not a palindrome") .
lines
isPal :: String -> Bool
isPal xs = xs == reverse xs
GHCi and Unsafe I/O
You can reduce this problem (the exception) to:
(
interact
callsgetContents
)The problem is that
stdin
(getContents
is reallyhGetContents stdin
) remains evaluated in GHCi in-between calls tomain
. If you look upstdin
, it's implemented as:To see why this is a problem, you could load this into GHCi:
Then, in GHCi:
Since we've used
unsafePerformIO
and told the compiler thatf
is a pure function, it thinks it doesn't need to evaluate it a second time. In the case ofstdin
, all of the initialization on the handle isn't run a second time and it's still in a semi-closed state (whichhGetContents
puts it in), which causes the exception. So I think that GHCi is "correct" in this case and the problem lies in the definition ofstdin
which is a practical convenience for compiled programs that will just evaluatestdin
once.Interact and Lazy I/O
As for why
interact
quits after a single line of input while theunlines . lines
version continues, let's try reducing that as well:If you test the above version, interact won't even wait for input before printing
response
. Why? Here's the source forinteract
(in GHC):getContents
is lazy I/O, and sincef
in this case doesn't needs
, nothing is read fromstdin
.If you change your test program to:
you should notice different behavior. And that suggests that in your original version (
test a = show 3
), the compiler is smart enough to realize that it only needs enough input to determine if the string read is empty or not (because if it's not empty, it doesn't need to know whata
is, it just needs to print"3"
). Since the input is presumably line-buffered on a terminal, it reads up until you press the return key.