用户应该使用/避免哪些Haskell(GHC)扩展？

Question

我已经有过几次GHC告诉我使用扩展的经验,但却发现当使用该扩展时,我使代码变得更加复杂,当一个简单的重构允许我坚持使用Haskell 98(现在2010)并有一个更直接的解决方案.

另一方面,有时候GADT或Rank2Types(很少是RankNTypes)的工作量少得多,代码也更清晰.

哪些扩展通常会掩盖更好设计的可能性,并且通常会改善它？如果有一些同时执行这两项工作,那么在决定使用该扩展之前,用户应该寻找什么(确定它们是否符合他们想要的解决方案)？

Answer 1

一个道德"好"扩展和道德"坏"扩展的临时列表 - 这是一个美学判断!

好的

坏

丑陋(但必要)

不确定

我不完全同意不可判定的实例.整体检查器非常保守,并且不允许许多合理的实例声明. (19认同)
是的,这是一个折腾.我认为初学者太容易接受,当他们应该重新设计时,然而,它确实使某些不可能的程序成为可能. (9认同)
元编程有什么难看的(即模板Haskell)？ (5认同)
@ SamTobin-Hochstadt这是我从问"模板Haskell有什么不好？"得到的外卖信息.问题不是元编程是丑陋的,但模板Haskell基本上没有做好实现安全元编程的工作.我同意仔细使用元编程对于推理一个程序是一个巨大的福音,因为它允许你超越原始语言的限制,并使表达形式更接近问题域的"语言". (4认同)
SQL理解很糟糕,"IncoherentInstances"不是吗？ (3认同)
@DonStewart,我会说"特定于域的语言是最终的抽象"(Paul Hudak),并且元编程是"简单推理代码"的重要工具. (2认同)
DSL很棒.Haskell中有许多优秀的DSL不使用元编程(Hudak的DSL都没有使用TH ......).我只是不同意元编程对于使代码更易于推理至关重要,因为分阶段计算的语义比非分阶段计算复杂得多. (2认同)