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

[Adrian Hey]

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