Some quick comments on the Haskell 1.3 proposal.
(1) In the design of Haskell 1.0, the type IOError was a bit of a
guess. It wasn't clear whether it defined too many or too few error
classes; it might even have been better to just replace IOError by type
string. By now, we have more experience, and I think the Haskell 1.3
designers should reconsider the design of IOError in light of this
experience.
(2) For similar reasons, it's not clear to me if the various
enumerated types connected with file handling, or the lack of an
enumerated type for interupts, are good choices. It would be helpful
to have some guiding principle, e.g., `make available the facilities
provided by Unix'. If, say, that's the principle we go for, then
channels and files should not be distinguished.
(3) It is clear why the definition of IO in terms of IOPrim is in the
document, but I am afraid that it also may be confusing, since of
course IO is simply a primitive type and need not be implemented in
terms of IOPrim. I think I'd rather see a very dry description, with
the definition of IO in terms of IOPrim relegated to a separate section
on motivation.
Cheers, -- P
