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

[James Cook]

On Dec 14, 2011, at 1:23 AM, Gregory Crosswhite wrote:

> 
> On Dec 13, 2011, at 3:32 AM, Bryan O'Sullivan wrote:
> 
>> Don't be silly. The purpose of some and many is to be used with combinators that are expected to fail sometimes. If you use them with combinators that always succeed, of course you're going to get an infinite loop.
> 
> Yes, but how can someone using a typeclass *know* whether a type has values that will always succeed?
> 

Every type with an instance of Alternative has values that always succeed, because Alternative extends Applicative.  "some (pure foo)" is questionable, if not meaningless, for all Alternative types.  The real distinction is whether there can be actions that sometimes succeed and sometimes don't.  For some types, such as Maybe and [], there cannot.  For other types, such as parsers, there can.

I don't want to get too deep into the discussion but I tend to agree that it would have been better if "some" and "many" had been put in their own class sitting on top of Alternative.  I don't know whether the pitfall is so large that it justifies a retroactive change, but I do know the threshold for such a justification can safely be a LOT lower in Haskell than in other languages.  Change doesn't hurt nearly as much in Haskell as in, say, Ruby because the compiler can very easily be made to do the "dirty work" of rejecting code that hasn't been updated.

Of course it's not totally painless.  It's at least an annoyance to update something and find your code fails to build (or worse, your code is fine but code you depend on fails to build), and people will inevitably get confused by out-of-date tutorials, documentation for old versions of the changed package, etc., but when it comes to actual knowledgeable users needing to get real work done, it's mostly just a matter of using "cabal fetch" to get any broken upstream dependencies, edit a few lines in those packages and in your own code (the compiler helpfully tells you exactly which lines to edit), and continuing on your merry way knowing you've fixed everything the change broke.

In any case, it does sound like better documentation is in order; even for types that do support them sensibly, "some" and "many" definitely have pitfalls.

-- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111214/9e4ac9e8/attachment.htm>