[Haskell-cafe] Re: [Haskell] Top Level <-

[Ganesh Sittampalam]

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