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

[Ganesh Sittampalam]

On Sat, 30 Aug 2008, Adrian Hey wrote:

> Ganesh Sittampalam wrote:
>> How do the implementers of Data.Unique know that they musn't let them be 
>> serialised/deserialised?
>
> 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?

> I think the whole thread local state thing is a complete red herring.
>
> I've never seen a convincing use case for it and I suspect the only

Well, I've never seen a convincing use case for global variables :-)

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

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

>> 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. Those rules aren't actually strong 
enough to provide a guarantee of process level scope.

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

Ganesh