<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">If you're OK with a little template Haskell and standalone-deriving, then you can use the trick discussed here:</div><div dir="ltr"><br></div><div dir="ltr"> <a href="https://stackoverflow.com/questions/45113205/is-there-a-way-to-shorten-this-deriving-clause">https://stackoverflow.com/questions/45113205/is-there-a-way-to-shorten-this-deriving-clause</a><br><div><br></div><div>Here's a concrete implementation in my case:</div><div><br></div><div> <a href="https://github.com/LeventErkok/sbv/blob/master/Data/SBV.hs#L407-L420">https://github.com/LeventErkok/sbv/blob/master/Data/SBV.hs#L407-L420</a></div><div><br></div><div>And a use-case:</div><div><br></div><div> <a href="https://github.com/LeventErkok/sbv/blob/master/Documentation/SBV/Examples/Queries/Enums.hs#L23-L27">https://github.com/LeventErkok/sbv/blob/master/Documentation/SBV/Examples/Queries/Enums.hs#L23-L27</a></div><div><br></div><div>Without that trick, the line would've looked like almost like what you had to write with `Count`.</div><div><br></div><div>I've used this trick for quite some time now, and it's both cheap and quite effective. I agree that a directly supported `deriving` syntax would be nicer, but TH fits the bill well here.</div><div><br></div><div>-Levent.</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 24, 2018 at 1:36 PM Harendra Kumar <<a href="mailto:harendra.kumar@gmail.com">harendra.kumar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>