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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
