On Saturday 14 July 2007 11:29, Michael Vanier wrote:
Albert,
Thanks for the very detailed reply! That's the great thing about this mailing list.
I find your description of seq somewhat disturbing. Is this behavior documented in the API? I can't find it there.
As I understand it seq is well-behaved. Though there is the x `seq` x = id trickiness and maybe some trickiness around undefined. The disturbing behaviour is a consequence of the inherent unsafeness of hGetContents. seq is being used to try and mitigate some of this unsafeness but that's not really the purpose of seq so you still have to be careful.
It suggests that perhaps there should be a really-truly-absolutely-I-mean-right-now-seq function that evaluates the first argument strictly no matter what (not that this should be something that gets used very frequently). Or are there reasons why this is not feasible?
Albert mentioned "return $! length c", that forces the whole lot because it's all needed to calculate the length. You could also look at Control.Parallel.Strategies. (I think) that it has classes and functions that let you define how to reduce to other than WHNF.
Sorry to belabor this. Learning to think lazily is IMO one of the hardest aspects of learning Haskell.
Like any unsafe operation if you can convince yourself that it will actually be safe go ahead and use it. But as Albert has pointed out there can be hidden complexity in proving this to yourself. There have been discussions on haskell-cafe previously about the risks of getContents, safe alternatives, whether it should be renamed unsafeGetContents, etc. Sorry I can't dredge up exact dates/subjects, maybe someone else can recall. Daniel