On Sat, Sep 19, 2009 at 6:53 PM, Ben Franksen
Cristiano Paris wrote:
Daniel Fischer wrote:
I would separate the reading of headers and bodies, reopening the files whose body is needed, for some (maybe compelling) reason he wants to do it differently.
Yes, that's the way Haskell forces you to do that as it's the only way for you to go safe.
I don't think it has anything to do with Haskell.
My sentence was to be understood in a positive way. I think this has a lot to do with Haskell, as it forbids you to write certain kinds of programs: this is a distinguished feature of all the static typed languages and more specifically in Haskell, which has a very expressive type system. In particular, you can't have a program that runs IO "out-of-order": if you really want to do that, you must use unsafe(Perform|Interleave)IO which is like cheating, in a way. Indeed, the only way to do that not using unsafePerformIO is to have a two stage reading, either making the body an IO action or having an intermediate data structure which represents a file whose body has not been read yet: in general this is safer, unless you know something about your program and can assure the compiler it won't behave badly with respect to side effects.
How would you do this in C? You'd pass a flag indicating whether to read the whole file or just the header. You can do the same in Haskell, of course, no lazy IO needed. The body remains undefined if the flag indicates header only. Even better wrap the body in a Maybe.
The difference is in the expressivity of the type system. In C I may use a NULL pointer indicating the body has not been read yet, but then the compiler won't enforce good uses of that pointer and can't assure you that in no way a NULL pointer would be ever dereferenced, leaving room for untested, uncaught bugs. In Haskell this is simply not possible.
... I have a hard time believing this is possible, if you demand that the files should not stay opened indefinitely. How is the runtime supposed to know whether to close the file or not? What you /can/ do is use unsafePerformIO to lazily re-open, read the body, and close the file, as soon as the body gets demanded. However, this is ugly and not advised.
Here in Cafè once I had a discussion about when is safe and advisable to use unsafePerformIO. I don't think this function is evil per-se and indeed THERE ARE situations where it's more elegant and clear implementing things using unsafePerformIO. I see it as way to tell the compiler "don't mind: I know what I'm doing". This is certainly true when using FFI to implement in C pure functions, but it's true in other situations, like mine, in which using unsafeInterleaveIO allows me to write my code cleanly and easily, separating IO from processing, and avoid having to read the files in a two-stage way. Of course, I can be wrong and I can't look forward to hearing from the wise people and argument againts my point.
Cheers Ben
Thanks. Cristiano