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) <span></span>but I see no reason to do that.<br><br>On Monday, 24 August 2015, Clinton Mead <<a href="mailto:clintonmead@gmail.com">clintonmead@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<span></span><br><br>On Monday, 24 August 2015, Miguel Mitrofanov <<a href="javascript:_e(%7B%7D,'cvml','miguelimo38@yandex.ru');" target="_blank">miguelimo38@yandex.ru</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
foo :: C a => a -> Int<br>
<br>
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<br>
<br>
a :: T<br>
a = ...<br>
<br>
b :: Int<br>
b = foo a<br>
<br>
you'll get a compile error. THAT is the problem.<br>
<br>
24.08.2015, 13:28, "Clinton Mead" <<a>clintonmead@gmail.com</a>>:<br>
> There's no new data. Class C already exists in another package. Data T already exists in another different package.<br>
><br>
> The options are:<br>
><br>
> a) Create a newtype MyT and an instance MyT of C.<br>
> b) Just create an orphan instance T of C.<br>
> c) Create a new class C1, forward its implementation to C, and add an instance T of C1.<br>
><br>
> I'm suggesting (c) is best, but I haven't seen this elsewhere, the debate is usually between (a) and (b).<br>
><br>
> 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.<br>
><br>
> On Monday, 24 August 2015, Miguel Mitrofanov <<a>miguelimo38@yandex.ru</a>> wrote:<br>
>> 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.<br>
>><br>
>> 24.08.2015, 12:55, "Clinton Mead" <<a>clintonmead@gmail.com</a>>:<br>
>>> 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?<br>
>>><br>
>>> On Monday, 24 August 2015, Erik Hesselink <<a>hesselink@gmail.com</a>> wrote:<br>
>>>> On 24 August 2015 at 09:18, Clinton Mead <<a>clintonmead@gmail.com</a>> wrote:<br>
>>>>> A second approach is an orphan instance. The recommendation here is to put<br>
>>>>> the orphan instances in their own module, so the user can choose to import<br>
>>>>> them.<br>
>>>>><br>
>>>>> This may works ok if your user is writing an executable. But what if your<br>
>>>>> user is writing a library themselves. But once, you, or your user, directly<br>
>>>>> uses one of the instances, they need to import it, and they pollute the<br>
>>>>> global instance namespace for anyone that uses their package.<br>
>>>><br>
>>>> For this reason, I think the recommended course of action is to make a<br>
>>>> canonical place for the instance, so that everyone can use it. For<br>
>>>> example, if you have a library 'foo' providing T, and a library 'bar'<br>
>>>> providing C, put the instance in a new package 'foo-bar' (or<br>
>>>> 'bar-foo'). Then everyone can use that one instance, since Haskell is<br>
>>>> built on the assumption that every type has one unique instance per<br>
>>>> class.<br>
>>>><br>
>>>>> I want to suggest a third option:<br>
>>>>><br>
>>>>> (3) Copying the class.<br>
>>>><br>
>>>> This would make a new distinct class, which means you can't call any<br>
>>>> methods which have the original class as the context (f :: C a => a -><br>
>>>> a) since that class won't exist for type T (you are trying to avoid<br>
>>>> defining that orphan instance). So I don't think this is usable in<br>
>>>> most cases, unless I'm missing something.<br>
>>>><br>
>>>> Erik<br>
>>> ,<br>
>>><br>
>>> _______________________________________________<br>
>>> Haskell-Cafe mailing list<br>
>>> <a>Haskell-Cafe@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote>
</blockquote>