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

[Ganesh Sittampalam]

On Sat, 30 Aug 2008, Adrian Hey wrote:

> Ganesh Sittampalam wrote:
>
>> Well, yes, but if I implemented a library in standard Haskell it would 
>> always be safely serialisable/deserialisable (I think). So the global 
>> variables hack somehow destroys that property - how do I work out why it 
>> does in some cases but not others?
>
> This has nothing to do with the use of global variables. If you have
> a set of values that are guaranteed to be distinct ("unique") and you
> add another random/arbitrary value to that set you have no way of
> knowing that it is different from any current member (other than
> searching the entire set, assuming it's available).

OK, never mind about this. I was thinking that referential transparency 
was violated by remoting, but since unique values can only be constructed 
in IO, I think I was wrong.

>> Well, I've never seen a convincing use case for global variables :-)
>
> Well apart from all the libs that couldn't be implemented with them...

They can't be implemented with an interface that is completely oblivious 
to the fact that the libraries require some state.

>> Dynamic loading and plugins work fine with standard Haskell now, because 
>> nothing in standard Haskell breaks them. The <- proposal might well break 
>> them, which is a significant downside for it.
>
> I don't see how, but if so <- bindings are not the cause of the
> brokeness. They'd still be broken using the unsafePerformIO hack.

Which places the unsafePerformIO hack at fault, seeing as it's unsafe and 
a hack and all :-) If <- was standard then it'd be up to everyone else to 
work round its limitations.

>> In general, the smaller the "world" that the Haskell standard lives in, the 
>> less it can interfere with other concerns. <- massively increases that 
>> world, by introducing the concept of a process scope.
>
> All IORefs,MVars,Chans scope across the entire process defined by main.
> Or at least they *should*, if they don't then something is already
> badly wrong somewhere. This has nothing to do with whether or not they
> appear at top level. This is what an IORef/MVar whatever is defined to
> be.

Their scope is where they can be used, and this is something we can 
explicitly track by inspecting the program text. If they are just used in 
one part of the program, their scope is limited to that part of the 
program.

> But then again, I'm sure that some that will be adamant that any way
> of making "global variables" is a hack. But they'll still be happy
> to go on using file IO, sockets etc regardless, blissfully unaware
> of the hacks they are dependent on :-)

I'm not sure of precisely what you mean here, but stdin, stdout and stderr 
are things provided by the OS to a process. That's what defines them as 
having process scope, not something the Haskell language or RTS does.

>> Those rules aren't actually strong enough to provide a guarantee of 
>> process level scope.
>
> The rules for <- bindings shouldn't have to guarantee this.
> This should be guaranteed by newMVar returning a new *MVar*, wherever
> it's used (for example).

The issue is whether the <- is run multiple times in a single process or 
not, rather than how the thing it calls behaves.

> I mean semantic faults, as in the proposal just doesn't do what it
> promises for some subtle reason.

It doesn't provide "once-only" semantics across an entire process in cases 
involving dynamic loading or two Haskell libraries together with RTS 
separately linked into the same C program. I don't know whether you intend 
that it does promise that or not, but it seems to be necessary for many of 
the applications that are used to justify it.

> If you consider not giving you thread local variables a fault I guess 
> you're entitled to that view, but this was never the intent of the 
> proposal in the first place (that's not what people are trying to do 
> when they use the unsafePerformIO hack).

The thread-local variables point was a relatively minor issue for me 
compared to the dynamic loading and related issues.

Cheers,

Ganesh