[Haskell-cafe] global variables

[John Meacham]

On Thu, May 17, 2007 at 11:00:18PM +0100, Jules Bean wrote:
> I'm not sure that's quite to the point. Clearly we can set up state at 
> the top of our main action:
> 
> main = do
>   sockstate <- initSocks
>   graphstate <- initGraphics
>   ...
>   disposeGraphics graphstate
>   disposeSocks sockstate
>   exit
> 
> 
> Voila. Mutable state which persists for our entire program.
> 
> Arguably it's a pain passing around the state explicitly. Alternatively, 
> you can argue that passing this stuff around explicitly makes code much 
> easier to reason about. And we know a dozen tricks to hide this stuff 
> (reader monads, state monads, withSocketsDo-style bracket constructs).
> 
> So I don't think this is really the issue, is it?
> 
> As I understood it, the issue was more about whether or not *library* 
> modules should be allowed to some 'set up' initialisation code to run at 
> the beginning of 'main' to start up their own global state. I was never 
> convinced this was a nice idea (I don't like the thought than an 
> 'import' alone can add hidden IO actions to main). Mind you, I'm not 
> convinced it's wrong, either. I think it's a hard one.

indeed. the whole issue is libraries. global state need not be visible
to users, but is certainly useful when hidden inside librarys to provide
efficient purely functional veneers for internal algorithms. 

I think restricting the actions to ones that don't have externally
visible effects is the way to go here for a couple reasons. 

 * I would very much hate for 'import' to have effects in and of itself.
 * it would disallow (or expose) the obvious 'lazy' approach to
   top-level IO, where you don't actually perform the IO until the first
   time the value is needed, then memoize it.

so, some sort of restricted ACIO monad is in order.

Also, there is the somewhat related 'ForeignData' proposal of mine, the
syntax is pretty much off the top of my head, but I think something like
this needs to go into the haskell FFI, 

http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignData

especially since it will sever the last need for C, allowing fully native
haskellp programs with the full power of C code. (plus, lots of
optimizatuons are available to the compiler when it sees the definitions
like this and it is really easy to implement)

        John

> 

-- 
John Meacham - ⑆repetae.net⑆john⑈