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