<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 25 Sep 2018 at 01:12, Oleg Grenrus <<a href="mailto:oleg.grenrus@iki.fi">oleg.grenrus@iki.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 24.09.2018 17:06, Harendra Kumar wrote:<br>
><br>
><br>
> On Mon, 24 Sep 2018 at 18:17, Oleg Grenrus <<a href="mailto:oleg.grenrus@iki.fi" target="_blank">oleg.grenrus@iki.fi</a><br>
> <mailto:<a href="mailto:oleg.grenrus@iki.fi" target="_blank">oleg.grenrus@iki.fi</a>>> wrote:<br>
><br>
>     The problem is that "All instances" is hard to pin point. We have<br>
>     open world assumption, so instances can be added later (in the<br>
>     dependency tree). Should they be cloned too? And even of you<br>
>     restrict to "instances visible at clonetype definition", that's<br>
>     IMHO not a good idea either, as it's implicit and volatile set<br>
>     (editing imports changes may change the set).<br>
><br>
><br>
> A clone type says "both the types are exactly the same in all<br>
> semantics except that they cannot be used interchangeably", it is just<br>
> like "type" except that the types are treated as being different. The<br>
> way visible instances change for the original type by editing imports,<br>
> the same way they change for the clone type as well, I do not see a<br>
> problem there. However, the two types may diverge if we define more<br>
> instances for any of them after cloning and that may potentially be a<br>
> source of confusion?<br>
<br>
If you want that, then the GeneralizedNewtypeDeriving is the solution.<br>
It's not so convinient, as you have to list the instances you need, but<br>
on the flip side of the coin is the "explicitness" of the deriving<br>
clause. GHC will barf if you forget an import for an instance you want,<br>
or if you have unused import. Often redundancy is your friend. Type<br>
annotations very often aren't necessary, but it's good practice to write<br>
them (e.g. for top-level definitions). So I'd say that not having<br>
`clonetype` is a feature.<br>
<br></blockquote><div> </div><div>That's where I started. I already use a newtype with GND for this, and it looks like this:</div><div><br></div><div><div>newtype Count = Count Int64</div><div>    deriving ( Eq</div><div>             , Read</div><div>             , Show</div><div>             , Enum</div><div>             , Bounded</div><div>             , Num</div><div>             , Real</div><div>             , Integral</div><div>             , Ord</div><div>             )</div></div><div><br></div><div>The problem is that most programmers are lazy or hard pressed for time and having to write a newtype with a big list of instances actually discourages the use of newtypes freely for this case, they may just make it a habit to let it go. We can't just deny this and say that programmers must be disciplined. They will often try taking the path of least effort. So in practice I am not sure what is better, being explicit or encouraging the use of distinct types and potentially avoiding bugs by doing so. What kind of actual problems/bugs may arise by not being explicit in this particular case?<br></div><div><br></div><div>-harendra</div></div></div></div>