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

Reply via email to