[Haskell-cafe] Alternative to newtypes or orphan instances
Clinton Mead
clintonmead at gmail.com
Mon Aug 24 10:45:29 UTC 2015
Why does 'foo' fail? The module that 'foo'is defined in still can see C. C
still exists. So as long as I import foo it should still work yes?
On Monday, 24 August 2015, Miguel Mitrofanov <miguelimo38 at yandex.ru> wrote:
> OK. There is no point in having a class C, if there is no functions to
> work with it. So, this "other package" likely contains some functions that
> take types (of that class) as input. Like this:
>
> foo :: C a => a -> Int
>
> You don't need class C if you aren't using any functions from the library.
> So, with your (c), if you try to do
>
> a :: T
> a = ...
>
> b :: Int
> b = foo a
>
> you'll get a compile error. THAT is the problem.
>
> 24.08.2015, 13:28, "Clinton Mead" <clintonmead at gmail.com <javascript:;>>:
> > 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
> <javascript:;>> 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/2a91e4f3/attachment.html>
More information about the Haskell-Cafe
mailing list