<div dir="ltr">Map is (you map over the values, not the keys).<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 1:14 AM Tony Morris <<a href="mailto:tonymorris@gmail.com">tonymorris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Map and Set are not. </p>
<div class="gmail_quote">On 01/06/2016 8:57 AM, "Jeffrey Brown" <<a href="mailto:jeffbrown.the@gmail.com" target="_blank">jeffbrown.the@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In Haskell typeclasses are based on what you want to do with something. If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, 2016 at 3:26 PM, Silent Leaf <span dir="ltr"><<a href="mailto:silent.leaf0@gmail.com" target="_blank">silent.leaf0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In fact it all comes down to trying to add partially a feature absent from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if they have different types.<br>Honestly i don't see the drawback of that name system, but i guess there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.<div><div><br><br>Le mercredi 1 juin 2016, Silent Leaf <<a href="mailto:silent.leaf0@gmail.com" target="_blank">silent.leaf0@gmail.com</a>> a écrit :<br>> All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions.<br>> So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.<br>> So, do i miss something? Is there in fact a class of that kind? If so why not?<br>> Thanks in advance! :)
</div></div><br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr">Jeffrey Benjamin Brown</div></div>
</div>
<br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
</blockquote></div></div>