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

[Ganesh Sittampalam]

On Sun, 31 Aug 2008, Adrian Hey wrote:

> Ganesh Sittampalam wrote:
>> On Sun, 31 Aug 2008, Adrian Hey wrote:
>> 
>>> Thanks for taking the time to do this Dan. I think the safety requirement 
>>> has been met, but I think it fails on the improved API. The main complaint 
>>> would be what I see as loss of modularity, in that somehow what should be 
>>> a small irrelevant detail of the implementation of some obscure module 
>>> somewhere has propogated it's way all the way upto main.
>> 
>> That's the key point, as I see it - they aren't "irrelevant details of the 
>> implementation", they are requirements the implementation places on its 
>> context in order for that implementation to be correct. So they should be 
>> communicated appropriately.
>
> Eh? Please illustrate your point with Data.Unique. What requirements
> does it place on it's context? (whatever that might mean :-)

It requires that its context initialises it precisely once.

Data.Unique is actually a poor example, as it is actually fine to 
initialise it multiple times as long as the resulting Unique values aren't 
treated as coming from the same datatype. But equally it can be 
implemented with IORefs, so it's not a good advert for the need for global 
variables.

> The real irony of your remark is that making APIs this robust is
> practically impossible *without* using global variables, and you're
> now saying that because they've done this work to eliminate these
> constraints they now have to be held to account for this with
> an absurd API.

I think there are two cases to consider here.

A Data.Unique style library, which requires genuinely *internal* state, 
and which is agnostic to having multiple copies of itself loaded 
simultaneously. In that case, there is no requirement for a process-level 
scope for <-, just that each instance of the library is only initialised 
once - the RTS can do this, as can any dynamic loader.

The other is some library that really cannot be safely loaded multiple 
times, because it depends on some lower-level shared resource. Such a 
library simply cannot be made safe without cooperation from the thing that 
controls that shared resource, because you cannot prevent a second copy of 
it being loaded by something you have no control over.

If the <- proposal were only about supporting the first of these 
applications, I would have far fewer objections to it. But it would have 
nothing to do with process-level scope, then.

Ganesh