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