<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am Mi., 26. Sep. 2018 um 16:50 Uhr schrieb Harendra Kumar <<a href="mailto:harendra.kumar@gmail.com">harendra.kumar@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>1) Nobody has pointed out what kind of bugs (with specific examples) will arise if we have something like clonetype. Are those bugs more dangerous or will consume more time compared to what we are trying to avoid in the first place? I am just trying to learn more about it, not claiming that this is better.</div></div></div></blockquote><div><br></div><div>I think the main danger here is that it is totally unclear what actually gets derived. Is there a written specification of what actually should be derived? How would such an extension interact with other already existing extensions and separate compilation/instances added at a later time? If this can't be specified exactly, concisely and intuitively, you *will* have a maintenance nightmare, just like with all implicit things.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>2) It is a real unsolvable problem that people take shortcuts when available,</div></div></div></blockquote><div><br></div><div>No, this is not unsolvable. People, especially newcomers to writing SW, must be educated, otherwise they will have to repeat the mistakes already made by lots of other people (a.k.a. "learning the hard way"):</div><div><br></div><div>   * What initially looks like a good cunning idea and/or like a shortcut will almost always turn out to be a nightmare later during maintenance and debugging.</div><div><br></div><div>   * Explicit is better than implicit. Note that this doesn't necessarily mean that you have to repeat yourself.</div><div><br></div><div>   * Only a tiny amount (I think I've read 5-10% several times) of time is actually spent programming things, the rest is spent understanding the problem, reading code (from other people or often even worse: your former past ;-), debugging and extending existing SW. Trying to optimize for the tiny fraction doesn't look like a good idea. This manifests in the mantra: "A good programming language doesn't make it easy to write correct SW, it makes it hard to write incorrect SW."</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> people will be people; this is also one of the reasons why Haskell is not so successful, other languages are easy in the short run. If we accept that this a fact of life, [...]</div></div></div></blockquote><div><br></div><div>This shouldn't easily be accepted, quite the opposite. A lot of users of "easy" and "concise" programming languages have learned the hard way that their beloved language doesn't scale at all, leading to the development of TypeScript (extending JavaScript), mypy (extending Python), Hack (extending PHP), etc.  What can be accepted as a fact of life is that there is often a tempting short route which is totally fine for throw-away scripts, quick hacks, etc., and there is a longer route, investing into the future. You have to choose...</div><div> </div><div>Coming back to the problem at hand: Even if we find a way to factor out the deriving-clauses to stay explicit, e.g. via the deriving synonyms proposal, I am not so sure if this is a good idea. How can you be sure when changing such a synonym that *all* affected types should really be changed? This would again be a maintenance nightmare.</div></div></div>