[Haskell-cafe] Alternative to newtypes or orphan instances

Clinton Mead clintonmead at gmail.com
Mon Aug 24 09:54:48 UTC 2015

The original class still exists, I can't see how making a new class based
on the old on affects that. Won't existing functions in modules which
import the old class instead of the new class continue to work?

On Monday, 24 August 2015, Erik Hesselink <hesselink at gmail.com> wrote:

> On 24 August 2015 at 09:18, Clinton Mead <clintonmead at gmail.com
> <javascript:;>> wrote:
> > A second approach is an orphan instance. The recommendation here is to
> put
> > the orphan instances in their own module, so the user can choose to
> import
> > them.
> >
> > This may works ok if your user is writing an executable. But what if your
> > user is writing a library themselves. But once, you, or your user,
> directly
> > uses one of the instances, they need to import it, and they pollute the
> > global instance namespace for anyone that uses their package.
> For this reason, I think the recommended course of action is to make a
> canonical place for the instance, so that everyone can use it. For
> example, if you have a library 'foo' providing T, and a library 'bar'
> providing C, put the instance in a new package 'foo-bar' (or
> 'bar-foo'). Then everyone can use that one instance, since Haskell is
> built on the assumption that every type has one unique instance per
> class.
> > I want to suggest a third option:
> >
> > (3) Copying the class.
> This would make a new distinct class, which means you can't call any
> methods which have the original class as the context (f :: C a => a ->
> a) since that class won't exist for type T (you are trying to avoid
> defining that orphan instance). So I don't think this is usable in
> most cases, unless I'm missing something.
> Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150824/ec9abcf5/attachment.html>

More information about the Haskell-Cafe mailing list