There's no new data. Class C already exists in another package. Data T already exists in another different package.<div><br></div><div>The options are:</div><div><br></div><div>a) Create a newtype MyT and an instance MyT of C.</div><div>b) Just create an orphan instance T of C.</div><div>c) Create a new class C1, forward its implementation to C, and add an instance T of C1.</div><div><br></div><div>I'm suggesting (c) is best, but I haven't seen this elsewhere, the debate is usually between (a) and (b).</div><div><br></div><div>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.<span></span><br><div><br></div><div><br>On Monday, 24 August 2015, Miguel Mitrofanov <<a href="mailto:miguelimo38@yandex.ru">miguelimo38@yandex.ru</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 href="javascript:;" onclick="_e(event, 'cvml', 'clintonmead@gmail.com')">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 href="javascript:;" onclick="_e(event, 'cvml', 'hesselink@gmail.com')">hesselink@gmail.com</a>> wrote:<br>
>> On 24 August 2015 at 09:18, Clinton Mead <<a href="javascript:;" onclick="_e(event, 'cvml', 'clintonmead@gmail.com')">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 href="javascript:;" onclick="_e(event, 'cvml', 'Haskell-Cafe@haskell.org')">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></div></div>