Re: [Haskell-cafe] Alternative to newtypes or orphan instances

24 Aug 2015


      After implementing the steps in (c), T is an instance of both C and C1, and
both those instances define foo the same way. The only way I see a problem
if is a module imports both C1 and C unqualified (they'll clash) but I see
no reason to do that.

On Monday, 24 August 2015, Clinton Mead  wrote:
...
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 javascript:_e(%7B%7D,'cvml','miguelimo38@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.
...
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 
wrote:
...
If, for your data, you create an instance of the new class — but not
...
...
24.08.2015, 12:55, "Clinton Mead" :
...
The original class still exists, I can't see how making a new class
...
...
...
On Monday, 24 August 2015, Erik Hesselink 
wrote:
...
...
On 24 August 2015 at 09:18, Clinton Mead 
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,
...
...
...
...
> uses one of the instances, they need to import it, and they pollute
24.08.2015, 13:28, "Clinton Mead" :
the original one, then you can't use all the machinery that expects input
being of the old class. Which is the point.
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?
directly
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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe