[Haskell-cafe] Splitting off many/some from Alternative

[Chris Dornan]

Well I do welcome such discussion.
 
This list should be for those of us who are perhaps not so brilliant or knowledgeable.
 
One of my biggest concerns with Haskell is that the complexity of some of the interfaces requires quite extraordinary demands on the user to use them correctly. I am not saying it is necessarily the case here, but I have observed it to be generally the case.
 
I wish people writing interfaces cared more about keeping them simple. Perhaps discussions of this kind might encourage folks writing them in future to try and meet some of their users in the middle – taking the necessary effort to simplify them rather than committing the user to a tournament of 6-dimensional chess to work out what is going on.
 
That is not true here (and I would definitely rather not give any examples), but I wonder whether there is something that those of us writing libraries could be doing to avoid exposing our users to such potential deep misunderstandings. (I know I have certainly been guilty of this.)
 
Long story short: I welcome sitting though such discussions and I suspect that even those in the know could profit from them.
Chris
 
 
 
From: haskell-cafe-bounces at haskell.org [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Bryan O'Sullivan
Sent: 14 December 2011 17:37
To: Gregory Crosswhite
Cc: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Splitting off many/some from Alternative
 
On Tue, Dec 13, 2011 at 10:23 PM, Gregory Crosswhite <gcrosswhite at gmail.com> wrote:
  
This way users of the classes will know whether their type has well-defined instance for some and many or not.
 
But that's precisely what the Alternative class is already for! If you are writing an Alternative instance at all, then you are asserting that it must be possible and reasonable to replicate the existing behaviour of some and many.
 
The fact that those functions are currently methods of the class is completely irrelevant, and perhaps this is a source of your confusion. They can be - and used to be - implemented as normal functions with Alternative class constraints, then at some point someone moved them into the class itself, solely to allow implementors to write faster versions.
 
I think we should take any further discussion off-list. Your messages from last night betray a deep misunderstanding that I'm not sure everyone else needs to sit through :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111214/47ae9eeb/attachment-0001.htm>