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

[Adrian Hey]

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 just does what it says on the tin AFAICS. There are no requirements
it places on "clients" (to use an OO term), as should any halfway
decent API IMO.

>> To me this seems completely at odds with what I thought was generally
>> accepted wisdom of how to write good maintainable, modular software.
>> Namely hiding as much implemention detail possible and keeping APIs
>> as simple and stable as they can be. I don't know if I'm alone in
>> that view nowadays.
> 
> It's no problem to hide implementation detail, but I don't think you 
> should hide the *requirement* of the implementation that it has 
> constraints on how it is called, namely that it requires once-only 
> initialisation or whatever.

No decent API should require this. Data.Unique certainly doesn't.
In fact is debatable whether any API should requre an initalisation
call at all before other stuff should be called (the other stuff
check initialisation has occured and do it itself if necessary).

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.

Seems like a clear case of "no good deed going unpunished" :-)

Regards
--
Adrian Hey