[Haskell-cafe] global variables

[Adrian Hey]

Jules Bean wrote:
> That's not my point. newIORef creates unique names (references). The 
> whole job of newIORef is to create unique names; unique names which 
> "refer to" little tiny bits of state parcelled up somewhere in that 
> mysterious IO monad. It is the scope of this uniqueness I'm talking 
> about: do libraries need these unique names to be unique over each 
> importer, over each thread, over each subprocess: consider a haskell 
> application server or a haskell OS... what is the correct domain of 
> uniqueness?

The scoping rules are exactly the same as for any other top level
identifier, whether or not exported or imported. There's no reason why
an importing module should know or care that one or more of the
identifiers it's importing is the result of a <- binding.

Should every module that imports the prelude get a different stdout?
(they currently don't of course)

> 'reentrant' is not the right word, although it's a related notion. I was 
> talking about libraries which can safely be initialised more than once, 
> for multiple clients, and they keep around 'separate' state for each 
> client/each time they are initialised. This kind of design is often a 
> precondition for being thread-safe; and it's often plain good design, 
> unless some external 'real world' uniqueness makes it impossible.

I don't see a problem here. The fact that an IO lib presents some
controlled interface one or more to real world resources (I.E.
resources where you can't simply conjour up a new ones by using
a "newResource" constructor) should not stop it being able to service
multiple clients or sessions. The socket API and indeed the OS itself
seem to be obvious examples of this (or even something really simple
like Data.Unique).

Or take a look at the hypothetical embedded device driver API I put
on the wiki. This makes a clear distinction between DeviceHandles and
DeviceSessionHandles (which will wrap the correspnding DeviceHandle).
Users cannot create new DeviceHandles but are free to create as many
DeviceSessionHandles with a particular device as they like.

Regards
--
Adrian Hey