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