[Haskell-cafe] Re: Global variables again

[Benjamin Franksen]

[we should really keep this on haskell-cafe because such lengthy discussions 
are what the cafe is for]

On Tuesday 23 November 2004 10:26, Adrian Hey wrote:
> 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.

Since the problem only appears in special situations, a general solution is 
not required, nor is it desirable (because of the danger of infection with 
the "global variable disease".)

> 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 evil is in the world in the form of C libraries with hidden global 
variables and hardware with non-readable registers.

What I am arguing for is to *contain* this disease by forcing a solution to 
happen outside of Haskell.

What you are arguing for (i.e. a general solution *in* Haskell) amounts to 
(deliberately) *spreading* the disease.

> The fact that one solution requires the use of a completely different
> programming language 

And that is exactly the point: In order to do evil you have to go somewhere 
else, preferably to where the problem originally came from. If it originated 
in C, go fix it on the C level. If originates in the OS, go fix it on the OS 
level. As for broken hardware, you should use a OS level mechanism, so that 
multiple initialization is prevented OS wide and not only per program run.

> 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. 

Yes it's plain missing and for good reasons. There are many things plainly 
missing from Haskell besides global variables.

> IMO this is not a very satisfactory situation for a language 
> that's advertised as "general purpose".

"General purpose" doesn't mean that any programming idiom is supported.

> > 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?

No, I didn't post code. I already said it's annecdotal evidence. For instance, 
I was talking about using the ONC/RPC implementation on VxWorks, which is 
broken because they internally use thread-local mutual state.

> 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.

I wasn't.

> > 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, 

True. I have never claimed that, though. What I claimed is that in the cases 
where they are necessary, FFI is probably used anyway, so it *is* workable to 
use a foreign language wrapper.

In order to convince me that this is wrong you could present a (real-world, no 
artificial requirements) example that does not require the use of FFI anyway. 
If you can do so (which I doubt) I might be willing to accept a 
compiler-supported standard library routine with a very long and very ugly 
name like

warningBadStyleUseOnlyIfAbolutelyNecessary_performOnlyOnce: IO a -> IO a

;-)

> especially when nobody 
> (other than yourself presumably) knows why you were using it in the first
> place. 

Not I. And it was for convenience only, as I proved by completely eliminating 
them without making the code any more complicated. I never claimed that this 
proves anything, it was just a personal experience.

BTW, the main reason they use global variable in C all the time is because 
it's just so damn convenient (at first) and *not* because there are problems 
otherwise unsolvable. (There are *very* few exceptions.)

> However, the existance of just one real world example where it does 
> appear unavoidable is pretty convincing evidence to the contrary IMO.

I agree that the alternatives are not a good *general* solution. I have been 
arguing that a general solution is not desirable.

> > 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.

There is no underlying problem, apart from interfacing evil hardware or 
foreign libraries. At least I know of none.

> > > 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?

Strange. I told you the reason. You even cited it. What about reading it, 
too ;-?

> I mean what extra safety does this buy you?

Nobody claimed that global variables are unsafe in any strict sense.

> Anybody can  
> still get at stdout and write anything they like to it.

Sure they can. They have been warned, though... ;-)

> 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.

To repeat myself once again: The latter version makes it clear to anyone 
looking at the code, that the stdout above

(a) might refer to something different from other results of getStdout 
elsewhere in the program (e.g. stdout might have been closed or re-opened)

(b) might refer to completely different things on different program runs (e.g. 
output of program is piped to some other process or even a socket).

Ben
-- 
Top level things with identity are evil.	-- Lennart Augustsson