
On Sun, Sep 5, 2010 at 8:40 AM, John Lato
On Sat, Sep 4, 2010 at 12:34 PM, David Menendez
wrote: On Fri, Sep 3, 2010 at 8:23 AM, John Lato
wrote: +1 for using the proper constraints, and especially for bringing over Pointed (and anything else that applies).
What's the argument for Pointed? Are there many types which are instances of Pointed but not Applicative? Are there many algorithms which require Pointed but not Applicative?
Having Pointed is categorically the right thing to do, which is why I argue for its inclusion.
Why is it categorically the right thing to do? When Conor McBride was promoting the use of Applicative (then called Idiom), he provided several instances and algorithms showing that it was a useful generalization of Monad, and it still took several years and a few papers[1] before Applicative found its way into the standard library. In other words, we didn't add Applicative and then discover Traversable later. Traversable was a big part of the argument for why Applicative is useful. [1] Idioms: applicative programming with effects http://www.cs.nott.ac.uk/~ctm/Idiom.pdf
Also, I think it would be prudent to avoid a situation with the possibility of turning into a rehash of the Functor/Applicative/Monad mess.
Granted, but let's not rush blindly in the opposite direction.
Are there any good reasons for not including it? Just because we don't have a use now doesn't mean it might not be useful in the future.
This is an argument for putting every member of the container API into
its own independent class. Why make things more complicated for little
or no benefit?
--
Dave Menendez