[Haskell-cafe] Alternative to newtypes or orphan instances

[Clinton Mead]

There's no new data. Class C already exists in another package. Data T
already exists in another different package.

The options are:

a) Create a newtype MyT and an instance MyT of C.
b) Just create an orphan instance T of C.
c) Create a new class C1, forward its implementation to C, and add an
instance T of C1.

I'm suggesting (c) is best, but I haven't seen this elsewhere, the debate
is usually between (a) and (b).

I don't really understand the problems you're proposing with (c), but I'm
not sure if that's because I'm misunderstanding you or I'm not explaining
myself well.


On Monday, 24 August 2015, Miguel Mitrofanov <miguelimo38 at yandex.ru> wrote:

> If, for your data, you create an instance of the new class — but not the
> original one, then you can't use all the machinery that expects input being
> of the old class. Which is the point.
>
> 24.08.2015, 12:55, "Clinton Mead" <clintonmead at gmail.com <javascript:;>>:
> > 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
> <javascript:;>> 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
> > ,
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org <javascript:;>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150824/d2978c27/attachment.html>