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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
