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