On Sun, Sep 5, 2010 at 7:18 PM, David Menendez <span dir="ltr"><<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, Sep 5, 2010 at 8:40 AM, John Lato <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sat, Sep 4, 2010 at 12:34 PM, David Menendez <<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>> wrote:<br>
>><br>
>> On Fri, Sep 3, 2010 at 8:23 AM, John Lato <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> wrote:<br>
>><br>
>> > +1 for using the proper constraints, and especially for bringing over<br>
>> > Pointed (and anything else that applies).<br>
>><br>
>> What's the argument for Pointed? Are there many types which are<br>
>> instances of Pointed but not Applicative? Are there many algorithms<br>
>> which require Pointed but not Applicative?<br>
><br>
> Having Pointed is categorically the right thing to do, which is why I argue<br>
> for its inclusion.<br>
<br>
</div>Why is it categorically the right thing to do?<br></blockquote><div><br></div><div>Because it's the proper abstraction underlying Applicative and Monad, as far as I understand category theory.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
When Conor McBride was promoting the use of Applicative (then called<br>
Idiom), he provided several instances and algorithms showing that it<br>
was a useful generalization of Monad, and it still took several years<br>
and a few papers[1] before Applicative found its way into the standard<br>
library.<br>
<br>
In other words, we didn't add Applicative and then discover<br>
Traversable later. Traversable was a big part of the argument for why<br>
Applicative is useful.<br></blockquote><div><br></div><div>I take this in favor of my point. Applicative wasn't considered useful, so it wasn't included. Then Conor McBride shows that it is useful, but at that point it was too late and now we're stuck with pure, return, ap, liftA2, liftM2, etc.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
[1] Idioms: applicative programming with effects<br>
<<a href="http://www.cs.nott.ac.uk/~ctm/Idiom.pdf" target="_blank">http://www.cs.nott.ac.uk/~ctm/Idiom.pdf</a>><br>
<div class="im"><br>
> Also, I think it would be prudent to avoid a situation<br>
> with the possibility of turning into a rehash of the<br>
> Functor/Applicative/Monad mess.<br>
<br>
</div>Granted, but let's not rush blindly in the opposite direction. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Are there any good reasons for not including it? Just because we don't have<br>
> a use now doesn't mean it might not be useful in the future.<br>
<br>
</div>This is an argument for putting every member of the container API into<br>
its own independent class. Why make things more complicated for little<br>
or no benefit?</blockquote><div><br></div><div>Not every member, but I would argue that type classes for containers should be much more fine-grained than anything I have seen proposed so far. I'm thinking of the collections provided by the .Net framework, i.e. a base ICollection interface, then IEnumerable, IList, and ISet on top of them. If an algorithm needs a list interface (integer-indexed, etc.), it can specify IList in the context, whereas if it only needs e.g. to check the length, or that a container is non-null, it can just specify ICollection and work with more data structures.</div>
<div><br></div><div>I would be in favor of breaking it down further, and then the ListClass, SetClass, etc. would likely be classes with no methods, just a particular combination of superclasses. Edison is a good model too, although again I would go further.</div>
<div><br></div><div>One category of containers that is currently impossible to express (with container-classes or Edison) is non-null data, e.g. SafeList. Adding support for these would be nice, and it would be easier with finer-grained dependencies. As an example, a List interface could work for both regular lists and SafeList's, but only if it didn't require Monoid (or similar) as a superclass constraint. That's hard to do with the current structure, but if you're just combining several type classes it's easy.</div>
<div><br></div><div>At a minimum, I think that having extra classes for the specifics of e.g. Map or Queue interfaces is required for maximum utility.</div><div><br></div><div>John</div><div><br></div></div>