[Haskell-cafe] programming style...and type classes...

[Tobias Dammers]

My rule of thumb is that if there is one obvious instance (or none) for
every given type, then your abstraction is a good candidate for a
typeclass; if multiple instances make sense, then it's a judgment call;
and if many instances could arbitrarily make sense or not depending on
the usage / circumstances, then it's probably not a good candidate for a
typeclass.

For example, Functor is a very good typeclass - every type can have
exactly zero or one lawful Functor instance; if you think about it a
little, this means that with Functor, you can never run into overlapping
or undecidable instances, and the open universe is a fairly benign
problem - even if you derive or implement an orphan instance, it will at
least be functionally and logically equivalent to other possible
instances.

Most of the typeclasses in base are tougher calls, but overall, I would
say they still make a lot of sense. I'd be hard pressed to come up with
a type that has more than one sensible Monad instance, for example.

Something like Aeson's ToJSON / FromJSON is kind of a judgment call -
On the one hand, they shouldn't be typeclasses, because ideally you want to
separate JSON format specifications from data types (i.e., the user code
of a given type should decide on the serialization format, not the type
itself), but on the other hand, more often than not one designs types
specifically for the purpose of representing a certain JSON schema, and
an extra translation step sits between these types and the actual domain
types (at least that's how I often do it).

On a side note; it's not like the open universe principle is a bad idea.
There are lots of benefits to be had here.

On Fri, Nov 04, 2016 at 09:57:31AM +0000, Nicholls, Mark wrote:
> 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!
> 
> i.e. the logic goes.
> Creating an open data abstraction is not a “proper” usage?
> But not knowing future extensions requirements is a reality?
> So having a language where data abstraction are open by default (unless you WANT to close them) is an attractive objective?
> Typeclasses provide this?
> Eureka!
> Becomes DISASTER?
> 
> 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)?
> 
> Once you know where the problems are…best steer clear….once you know the pitfalls, you can use them “properly” (successfully)?
> 
> (ironically the process of finding the problems IS not using them properly!...but that’s life I think).
> 
> 
> 
> CONFIDENTIALITY NOTICE
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.

> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


-- 
Tobias Dammers - tdammers at gmail.com