[Haskell-cafe] Re: [Haskell] Top Level <-

[Duncan Coutts]

This topic came up in #haskell this evening...

On Sun, 2008-08-24 at 16:12 -0700, Ashley Yakeley wrote:
> 1. Global mutable state. For instance, here's the count variable for 
> Data.Unique rewritten:
> 
>    uniqSource :: MVar Integer
>    uniqSource <- newMVarTL 0
> 
> Isn't that much nicer?
> <http://haskell.org/haskellwiki/Top_level_mutable_state>

It's nicer syntax but it's still not true. There's still no such thing
as a global variable. There's always a scope.

In this case what scope are we looking for? Process scope? Only one
instance of uniqSource per process? If so, it's not right. We can link
in multiple copies of a package and thereby end up with multiple
instances (this really happens, it's not a far fetched scenario).
So uniqSource is a package-name/version scope mutable variable.

To get the right thing for the annoying C libs that have 'global' init
and finalise functions you need something else. Not actually process
scope, that's too wide. You need exactly the same scope as the system
linker is using, so that we get one variable per instance of the C
library linked into the process. Consider a process using several dlls
where each one links to a C lib that needs 'global' initialisation, we
must have exactly one 'global' var instance per dll in this case because
that's the linker namespace scope.

The scope you need depends on the application. A language extension like
this is likely to only cover package-name/version scope, not scopes like
thread, OS thread, rts instance, linker, process, user account, OS,
subnet, interweb, planet etc.

So in practise, what scopes do we often need, and
does package-name/version scope correspond to many of those use cases?

Duncan