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