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
