[Haskell-cafe] global variables

[Adrian Hey]

Jules Bean wrote:
>> I've pretty much convinced it's wrong. There should be one and only
>> one "main" from which all subsequent IO activity derives. But creating
>> internal state in the form of mutable data structures is not an IO
>> activity. It just so happens that at the moment the only way to do this
>> is newIORef :: a -> IO(IORef a), but this need not be so (readIORef and
>> writeIORef are IO activities, but newIORef isn't).
>>
> 
> I find this point rather slippery. 'newIORef' is a unique-name-provider, 
> but 'unique over what'? When a module is imported twice, should it not 
> create new unique names?

No, it's just binding a name to a value, same as any other binding.
The difference is unlike normal top level bindings, that name is not
"equal to" any other expression. It just "is", if you get what I mean
(I'm sure you do). That's why the proposed syntax borrows the <- from
do expressions.

>> If it's necessary that there is only one libWhateverState to preserve
>> safety properties (because the state must be kept in sync with what's
>> really being done to "the world", of which there is also only one) then
>> what's the point of making it a parameter (the lib is not truly
>> parameterisable by that state).
> 
> A slightly irrational point of concern in my mind is that by encouraging 
> this practice, we encourage lazy library design.

Yes, this is slightly irrational :-)

> A large proportion of
> libraries in fact *can* be written as "reentrant" in this sense, and
> truly are parameterisable by their state.

I can't help being sceptical about this. AFAICS it doesn't matter how
many explicit state handles you tack on to the left of the
"-> IO Whatever", the fact that the whole lot ends in "-> IO Whatever"
means there's almost certainly some state left unaccounted for and
unparameterised (calls the OS are missing an OS state handle for
example).

Also, I don't really understand what you mean by "reentrant" in this
context. Are you talking about thread safety? (I guess not) Are you
implying that APIs of IO libs that mutate Haskell "global" state are
some how different from other IO APIs which mutate other "global" state
(such as OS state or "world state")? Are they deficient in some way?
If so, how can you tell the difference?

Regards
--
Adrian Hey