<div dir="ltr"><div><div>More that one Monad instance is actually pretty easy: type String -> (String, a) has different monad instances if you treat it as a State monad, or as a combination of Reader and Writer. Thanks to Denis Moskvin for inspiration.<br></div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 4, 2016 at 2:29 PM, Tobias Dammers <span dir="ltr"><<a href="mailto:tdammers@gmail.com" target="_blank">tdammers@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My rule of thumb is that if there is one obvious instance (or none) for<br>
every given type, then your abstraction is a good candidate for a<br>
typeclass; if multiple instances make sense, then it's a judgment call;<br>
and if many instances could arbitrarily make sense or not depending on<br>
the usage / circumstances, then it's probably not a good candidate for a<br>
typeclass.<br>
<br>
For example, Functor is a very good typeclass - every type can have<br>
exactly zero or one lawful Functor instance; if you think about it a<br>
little, this means that with Functor, you can never run into overlapping<br>
or undecidable instances, and the open universe is a fairly benign<br>
problem - even if you derive or implement an orphan instance, it will at<br>
least be functionally and logically equivalent to other possible<br>
instances.<br>
<br>
Most of the typeclasses in base are tougher calls, but overall, I would<br>
say they still make a lot of sense. I'd be hard pressed to come up with<br>
a type that has more than one sensible Monad instance, for example.<br>
<br>
Something like Aeson's ToJSON / FromJSON is kind of a judgment call -<br>
On the one hand, they shouldn't be typeclasses, because ideally you want to<br>
separate JSON format specifications from data types (i.e., the user code<br>
of a given type should decide on the serialization format, not the type<br>
itself), but on the other hand, more often than not one designs types<br>
specifically for the purpose of representing a certain JSON schema, and<br>
an extra translation step sits between these types and the actual domain<br>
types (at least that's how I often do it).<br>
<br>
On a side note; it's not like the open universe principle is a bad idea.<br>
There are lots of benefits to be had here.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 04, 2016 at 09:57:31AM +0000, Nicholls, Mark wrote:<br>
> I’m nervous of the statement “used properly”…it’s a bit tautological, and the inference is often used the wrong way around…i.e. if it doesn’t work you didn’t use it properly….and if it did…then you did!<br>
><br>
> i.e. the logic goes.<br>
> Creating an open data abstraction is not a “proper” usage?<br>
> But not knowing future extensions requirements is a reality?<br>
> So having a language where data abstraction are open by default (unless you WANT to close them) is an attractive objective?<br>
> Typeclasses provide this?<br>
> Eureka!<br>
> Becomes DISASTER?<br>
><br>
> So is the objection is really empirical ?…i.e. typeclasses will cause you problems IF you work like this (and you don’t know what you’re doing)?<br>
><br>
> Once you know where the problems are…best steer clear….once you know the pitfalls, you can use them “properly” (successfully)?<br>
><br>
> (ironically the process of finding the problems IS not using them properly!...but that’s life I think).<br>
><br>
><br>
><br>
> CONFIDENTIALITY NOTICE<br>
><br>
> This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.<br>
><br>
> While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.<br>
><br>
> Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.<br>
><br>
> MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.<br>
<br>
</div></div><span class="im HOEnZb">> ______________________________<wbr>_________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Tobias Dammers - <a href="mailto:tdammers@gmail.com">tdammers@gmail.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br></div>