<div dir="ltr">Since this is a basic use case, I was originally looking for a language solution that is extremely easy to use, intuitive and can be used by newcomers without having to learn the tricks. The TH solution solves the repetition problem, but not the initial inertia to use it, and we will have to use TH in almost all our programs. The deriving synonym extension that Li-yao mentioned earlier is perhaps a better solution than TH if implemented.<div><br></div><div>-harendra</div><br><div class="gmail_quote"><div dir="ltr">On Tue, 25 Sep 2018 at 02:13, Levent Erkok <<a href="mailto:erkokl@gmail.com">erkokl@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"><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</blockquote></div></div>