| From this is is not at all apparent to the user that
| evaluating a top-level binding of type IO () will lead to constructing
| and caching an object such as=20
|
| main =3D putStr "" >> putStr "" >> putStr "" >> mapM_ putStr (repeat "")
|
| corresponding to the view that >> is a constructor.=20
I disagree, and would use simple equational reasoning to justify it.
The relevant, simplified clauses in the definitions would be:
mapM_ f (x:xs) = f x >> mapM_ f xs
repeat x = x : repeat x
And from these one can readily deduce that:
mapM_ putStr (repeat "")
===> mapM_ putStr ("" : repeat "")
===> putStr "" >> mapM_ putStr (repeat "")
===> putStr "" >> mapM_ putStr ("" : repeat "")
===> putStr "" >> putStr "" >> mapM_ putStr (repeat "")
===> putStr "" >> putStr "" >> mapM_ putStr ("" : repeat "")
===> putStr "" >> putStr "" >> putStr "" >> mapM_ putStr (repeat "")
===> etc...
The increasing size of this expression now seems very clear. What you
seem to be saying is that, because IO is an abstract type, you can't be
sure whether this ever-expanding term might somehow be contracted as a
result of `executing' putStr and >>. I think it is fairly easy to see
that can't happen by replacing "" in the above by some other, nonempty
string. Now, as the recursion unfolds, the size string to be output will
increase at a steady pace, and so will the space needed to store it.
(Similarly, replace (repeat "") with (show [1..]) to explain why main
won't be (can't be) converted automatically into a cyclic structure.)
| Now, with the (welcome) existence of runhugs
As I said before, the needs of interpreters and compilers (which is what
runhugs provides, in effect) are not always the same. In this case,
maybe runhugs should take special steps to prevent caching of main.
Or perhaps it should be looking for a function hugsMain :: () -> IO ()
instead of main :: IO (), which it could then use to construct and
evaluate a fresh (and hence unshared) function application (hugsMain ()),
without the space leak.
All the best,
Mark
