On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC
interface?
A value of type Unique you mean? This isn't possible. Data.Unique has
been designed so cannot be Shown/Read or otherwise
serialised/deserialised (for obvious reasons I guess).
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised? What stops the same rule from applying to
Data.Random?
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.
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.
(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.
Cheers,
Ganesh
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
