On Monday 22 Nov 2004 4:03 pm, Benjamin Franksen wrote:
This is getting ridiculous. At least two workable alternatives have been presented:
- C wrapper (especially if your library is doing FFI anyway) - OS named semaphores
Neither of these alternatives is a workable general solution. There are several significant problems with both, but by far the most significant problem (at least if you believe that top level mutable state is evil) is that they both rely on the use of top level mutable state. If this is evil it is surely just as evil in C or OS supplied resources as it is in Haskell. The fact that one solution requires the use of a completely different programming language and the other requires the use of a library which could not be implemented in Haskell (not without using unsafePerformIO anyway) must be telling us that there something that's just plain missing from Haskell. IMO this is not a very satisfactory situation for a language that's advertised as "general purpose".
Further, as for "evidence or credible justification" for the my claim, you can gather it from the numerous real-life examples I gave, and which you chose to ignore or at least found not worthy of any comment.
I have no idea what examples you're talking about. Did you post any code? If so, I must have missed it for some reason. Perhaps your're refering to your elimination of unsafePerformIO from a library you were writing. It's not really possible to comment on the significance of you being able to eliminate top level mutable state in this case without knowing why you were using it in the first place.
Of course, these examples are only annecdotal but I think this is better than a completely artificial requirement (like your "oneShot").
Being able to avoid the use of top level mutable state sometimes (or even quite often) is not proof that it's unnecessary, especially when nobody (other than yourself presumably) knows why you were using it in the first place. However, the existance of just one real world example where it does appear unavoidable is pretty convincing evidence to the contrary IMO. It may yet prove to be avoidable, but nobody has managed to show that and I certainly can't think of a way.
You have been asked more than once to present a *real-life* example to illustrate that
(a) global variables are necessary (and not just convenient), (b) both above mentioned alternatives are indeed unworkable.
I knew this would happen. I was asked to provide an example and I *did*. I gave the simplest possible example I had of the more general problem, and now this whole thread has consisted of either repeated denials of the reality of even this simple problem (something you've just done again) or protracted discussions over various half baked non-solutions to this one particular problem (such as those you identify above) without seeing the real underlying general problem. (See my response to Keaan) You have the same basic problem when dealing with any unique stateful resource. Even the state handle passing solution that I believe yourself, Keaan and Lennart would advocate is unsafe without using top level mutable state one way or another (a problem that could be fixed quite easily by using "oneShot" at the top level I might add).
You have yet to explain how you propose to deal with stdout etc..
I see absolutely no reason why stdxxx must or should be top-level mutable objects. They can and should be treated in the same way as environment and command line arguments, i.e.
getArgs :: IO [String] getEnv :: String -> IO String getStdin, getStdout, getStderr :: IO Handle
Note that (just like environment and command line arguments) these handles may refer to completely different things on different program runs.
Sure, Peter Simons suggested the same thing. I have no great objection, but why do this? I mean what extra safety does this buy you? Anybody can still get at stdout and write anything they like to it. The only difference is that instead of writing.. do ... foo stdout ... ..they now have to write.. do ... stdout <- getStdout foo stdout ... I don't see why the former should be regarded as a source of great evil which is somehow eliminated by the latter. Regards -- Adrian Hey