[Haskell-cafe] Re: [Haskell] Top Level <-
ganesh at earth.li
Sat Aug 30 07:24:28 EDT 2008
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
> 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
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.
More information about the Haskell-Cafe