[moving to haskell-cafe] Sorry for the long post. On Sunday 07 November 2004 22:55, Adrian Hey wrote:
On Sunday 07 Nov 2004 1:45 pm, Benjamin Franksen wrote:
It's a similar advantage as using the IO monad has over allowing arbitrary side-effects in functions: The IO monad gives you a clear separation between stuff that has (side-) effects (i.e. depends on the real word) and pure functions (which don't). Abandoning global variables gives you a clear separation of stuff that depends on initialized state and other stuff that does not depend on it.
I don't agree. Hidden dependencies are a fact of life with stateful programming in general and IO monad in particular. Making some references explicit arguments (as you seem to be suggesting) does not eliminate the problem, it merely complicates an api for no good reason.
You have point here: hidden dependencies are something that is inherently possible in the IO monad. You can for instance easily create global variables using the FFI without resorting to unsafePerformIO. I'll take back what I said above. But I maintain that it is a good idea to avoid hiding dependencies if possible.
Hiding internal state dependencies is a *good thing*. The trick is organise the dependencies and provide a robust "idiot proof" api so that users don't have to know about the internal organisation and any dependencies.
Oh, but the user *has* to know about them. The user must call the init routine before using otehr routines of the library, remember? Why are you against the type checker reminding her? I know a lot of those "idiot proof" libraries: "You need to call X then call Y but not if Z was called before..." One of the ideas behind using functions with arguments and a static type system is to encode dependencies so that the compiler can enforce them. And BTW what if your idiot proof initialization routine needs arguments to configure the library? Is the user still allowed to call it from several places in his code, now with possibly different arguments? And with what effect?
I don't believe this is a new (or controversial) idea. Its the basic idea behind stateful modular or OO programming. All the user sees is a set of actions which collectively deliver on a promise (by unknown means).
OO is the best argument *against* global variables. Pure OO languages have *no* hidden global state. In every real OO programm you have the dependency explicit, since you always need a "target" object on which to invoke methods. It doesn't matter that you write "object.f" instead of "f object" as you would in Haskell. I have never heard anyone using an OO language complain about that. The two best OO languages I know of are Eiffel and O'Haskell/Timber. Both do not have global variables. Eiffel has 'once' routines which seem similar to be what you are after. Timber doesn't even have top-level IO actions, instead everything you need from the environment is given as an argument to main. Mark that Timber is used for real-time control, an inherently stateful and IO intensive field. Your opinion that it automatically leads to a horrible API if you have to pass the initialized state around amounts to saying that in an OO language like Eiffel only libraries with horribly inconvenient APIs can be written. This is ridiculous. Even in C++ using global variables is nowadays generally regarded as bad design, especially for libraries.
[...] You know that IO actions have (side-) effects, so you would take care that the actions get executed as many times as is apropriate. If the library docs indicate that it makes no sense to call it twice, why would you do so?
Given such a statement about realInit you wouldn't (or to be more precise, given a statement that calling it twice or more will really screw things up).
I would be really interested to know what kind of init action you are talking about, that so badly screws everything up if called twice. This is not rethoric, I mean it.
But the question is *how* is the user to ensure that it is only called once. I see no other way than the darned awkward alternative I gave.
We have an interesting patt situation here: You argue that you want a feature so that you can enforce that a routine is called *at most* once. I argue that if you do this by hiding state dependencies, you are loosing the ability to enforce that it is called *at least* once. You argue that it might be catastrophic if the library initialized more than once. I argue that it is usually catastrophic (with this I mean core dump or at least exception if it is programmed defensively) if you don't initialize it at all.
I suppose the other alternative is the noddy realInit is only used once in an action which is only used once, in an action .. from main (which is only used once hopefully). Is this what you have in mind?
It's the same patt as above: If you do it your way, you have the problem with ensuring that it gets called at least once before you call routines that depend on it. And that gets *really* hard as soon as you have concurrent threads. Maybe we should look for a solution that can enforce *both* invariants, "at least once" as well as "at most once"? Its only that I can't see such a solution and therefore my preferences would be to redesign 'realInit' in such a way that calling it twice is not fatal but just creates another 'instance' (can't be more specific without knowing what the library does).
The behaviour of (and consequent constraints on correct useage of) realInit and putString are very different. Must I eloborate them?
True, I can't see any constraints on correct usage of 'putString' that aren't enforced by the type checker. And that is exactly how it should be. Maybe the problem with your 'realInit' is that it needs such constraints? Again, giving an example might convince me that these constraints are inherent to the problem domain and can't be worked around.
It doesn't seem very attractive to users either (considerably complicates their code and places the burden on them to "get it right").
It may seem so at first, but I think it's a delusion.
Trust me on this, for whatever reason, it's absolutely vital that realInit is used 0 or 1 times only, 2 or more is a catastrophic error.
I would very much like to trust you, but why can't you give us an example? Are you talking about misssion-critical stuff like controlling an airplane? But you don't initialize a library in full flight, do you? So why is it catastrophic and what exactly does that mean? I thought you mean core cump, but I am no longer sure... Maybe the reason is that it calls out to C libraries with a broken API? (I know of enough such libraries, and interfacing them in a clean manner is sometimes a pain in the ass.)
So I'll ask again. Please provide a simpler _and_ safer alternative (some real Haskell code please).
And I'll ask again for an example to convince me of the necessity.
At the moment I cannot imagine a well designed library interface where user code would be considerably complicated if no global variables were used. But maybe you have a good example at hand to prove that this is merely due to lack of imagination on my side, and that I was extremely lucky with the HWS? ;-)
Indeed, I believe this is the case. I'm guessing of course, but I imagine all your IO is done via standard Haskell library calls (socket API or whatever), in which case they will hide a lot of the stateful compexity of their implementation already.
I don't know about the latter. I do know that there are no constraints on usage in the form of "this must be called before that", besides the ones automatically enforced by the type system. An exception might be the posix libraries, but they are only a thin layer over a badly designed C API. I could be wrong, but I doubt that there is lots of hidden state in the Haskell part. I once wrote a Haskell binding to a C library for a special network protocol. I never even considered using unsafePerformIO except for C routines that were actually pure functions. What I *did* need to consider and work around was that the C API was in some places hiding global state, which was *very* bad. Another example: Have you ever been using ONC/RPC (Remote Procedure Call)? I saw implementations that came with a real-time multithreaded OS where the docs said, more or less: "All created objects such as client handle may only be used from the thread that created them." *That* is a horrible API, because it means you can not pass these objects around freely but have to make sure your routine isn't called from the "wrong" thread! And the reason for this restriction was (of course) that the library was hiding state inside thread-local variables.
If so it seems to me you're using the fact that somebody has already solved the problem for you as an argument that no solution is necessary.
Maybe. We can talk in "if" sentences until we both die of old age.
(It would be interesting to see what the api's of the libraries you're using would look like, if they had been designed according to the principles you're advocating).
Yes, that would be interesting. And it is not a matter of me holding up holy principles against an evil reality. I am talking about practical considerations, not ideals. I hope I've made that clear with the above examples. Cheers, Ben