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

[Miguel]

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.


On Fri, Nov 4, 2016 at 2:29 PM, Tobias Dammers <tdammers at gmail.com> wrote:

> 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
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161104/fd37dc18/attachment.html>