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

[Adrian Hey]

Ganesh Sittampalam wrote:
> On Sat, 30 Aug 2008, Adrian Hey wrote:
>> Because if you could take a String and convert it to a Unique there
>> would be no guarantee that result was *unique*.
> 
> 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).

> 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...

>> reason these to issues have become linked is that some folk are so
>> convinced that "global variables are evil", they mistakenly think
>> thread local variables must be less evil (because they are "less
>> global").
> 
> I don't think they're less evil, just that you might want them for the 
> same sorts of reasons you might want global variables.

"Global variables" are needed to ensure important safety properties,
but the only reasons I've seen people give for thread local variables
is that explicit state threading is just so tiresome and ugly. Well
that may be (wouldn't disagree), but I'm not aware of any library
that simply couldn't be implemented without them.

>> If plugins breaks is down to plugins to fix itself, at least until 
>> such time as a suitable formal theory of plugins has been developed so 
>> it can become standard Haskell :-)
> 
> 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.

> 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.

> 
>>> It's a hack that isn't robust in many situations. We should find 
>>> better ways to do it, not standardise it.
>>
>> Nobody's talking about standardising the current hack. This the whole
>> point of the top level <- proposal,
> 
> It just amounts to giving the current hack some nicer syntax and stating 
> some rules under which it can be used.

No, the unsafePerformIO hack is a hack because it's *unsound*. The
compiler doesn't know how to translate this into code that does
what the programmer intended. Fortunately ghc at least does have
a couple of flags that give the intended result (we hope).

The new binding syntax is nicer, but it's real purpose is to leave the
compiler no "wriggle room" when interpreting the programmers intent.

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 :-)

> 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).

>> which JM seems to think is sound enough for incorporation into JHC 
>> (correctly IMO). Nobody's found fault with it, other than the usual 
>> global variables are evil mantra :-)
> 
> Several people have found faults with it, you've just ignored or 
> dismissed them. No doubt from your perspective the faults are irrelevant 
> or untrue, but that's not my perspective.

I mean semantic faults, as in the proposal just doesn't do what it
promises for some subtle reason. 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).

Regards
--
Adrian Hey