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*.
What stops the same rule from applying to Data.Random?
Well the only data type defined by this is StdGen, which is a Read/Show instance. I guess there's no semantic problem with that (can't think of one off hand myself).
Also what if I want a thread-local variable?
Well actually I would say that threads are bad concurrency model so I'm not keen on thread local state at all. Mainly because I'd like to get rid of threads, but also a few other doubts even if we keep threads.
Even if you don't like them, people still use them.
AFAICS this is irrelvant for the present discussions as Haskell doesn't support thread local variable thingies. If it ever does being precise about that is someone elses problem.
The fact that your proposal isn't general enough to handle them is a mark against it; standardised language features should be widely applicable, and as orthogonal as possible to other considerations.
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 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"). Anyway, if you understand the reasons why all the real world libraries that do currently use "global variables" do this, it's not hard to see why they don't want this to be thread local (it would break all the safety properties they're trying to ensure). So whatever problem thread local variables might solve, it isn't this one.
For the time being the scope of IORefs/MVars/Chans is (and should remain) whatever process is described by main (whether or not they appear at top level).
And if main isn't the entry point? This comes back to my questions about dynamic loading.
Well you're talking about some non-standard Haskell, so with this and other non standard stuff (like plugins etc) I guess the answer is it's up to whoever's doing this to make sure they do it right. I can't comment further as I don't know what it is they're trying to do, but AFAICS it's not a language design issue at present. 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 :-)
(I.E. Just making existing practice *safe*, at least in the sense that the compiler ain't gonna fcuk it up with INLINING or CSE and every one understands what is and isn't safe in ACIO)
Creating new language features means defining their semantics rather more clearly than just "no inlining or cse", IMO.
I wouldn't even know how to go about that to the satisfaction of purists. But "global variables" *are* being used whether or not the top level <- bindings are implemented. They're in the standard libraries!
So if this stuff matters someone had better figure it out :-)
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, 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 :-) Regards -- Adrian Hey