Robert Dockins wrote:
On May 23, 2006, at 9:50 AM, Paul Hudak wrote:
If you disagree, then please tell me which features in Haskell (a particular I/O command, perhaps?) cannot be modelled as a function.
IO.hGetContents? I suspect the result of using hGetContents on a file you have open for writing in the same program can't be modeled as a pure function; at best you can say it depends on the order of evaluation which isn't defined. Not that it's necessarily a huge blow to your argument (hGetContents is viewed with some suspicion anyway), but it is a Haskell98 feature.
Ah yes, operations involving file handles are a good example, but I think the problem here is that we don't actually have a formal semantics for what's supposed to happen. I recall seeing threads about this in the past, where in particular the interactions of lazy evaluation with opening and closing files was being debated. But, I would argue that in principle we COULD (and probably should) specify a deterministic semantics if someone were willing to sit down and spell it out.
Things obviously get more complicated in the presence of concurrency. I'm not certain, but I believe some of the memory consistency models being discussed for Haskell' are not expressible using a non-deterministic merge, which basically assumes that all program actions are serializable.
http://www.haskell.org//pipermail/haskell-prime/2006-March/001168.html
Yes, I agree, although I specifically excluded concurrency from my argument. -Paul