【问题标题】:Which Haskell (GHC) extensions should users use/avoid?用户应该使用/避免哪些 Haskell (GHC) 扩展?
【发布时间】:2012-06-01 06:02:27
【问题描述】:

我有过几次让 GHC 告诉我使用扩展的经验,只是发现在使用该扩展时,我使代码变得更加复杂,而一个简单的重构就可以让我坚持使用 Haskell 98(现为2010)并有更直接的解决方案。

另一方面,有时 GADT 或 Rank2Types(很少是 RankNTypes)可以减少工作量和更简洁的代码。

哪些扩展通常会掩盖更好设计的可能性,哪些通常会改进它?如果有一些两者兼而有之,那么用户在决定使用该扩展程序之前应该寻找什么(确定他们想要的解决方案是否正确)?

(另见Should I use GHC Haskell extensions or not?

【问题讨论】:

  • 相似,但不同。虽然这个问题是关于扩展的“安全性”,但 John 的问题是关于设计带有和不带有扩展的代码的收益。
  • 这是一个非常困难的问题:一些扩展非常通用,使新类型的编程成为可能,一些具有高度针对性,旨在解决特定的、不可能完成的任务。
  • 唐斯图尔特:是的,我同意。回想起来,我希望我已经关注了这个问题以及影响类型检查器的那些扩展。非常感谢您的回答。
  • Stephen Diehl 列出了扩展名,说明它们是否是良性的:dev.stephendiehl.com/hask/#language-extensions

标签: haskell language-extension


【解决方案1】:

道德上“好的”扩展和道德上“坏”的扩展的特别列表 - 这是一种审美判断!

好人

  • GADT
  • 并行列表推导
  • 模式保护
  • Monad 理解
  • 元组部分
  • 记录通配符
  • 空数据声明
  • 现有类型
  • 广义的新类型推导
  • MPTC + FD
  • 类型族
  • 显式量化
  • 高阶多态性
  • 词法范围的 tyvars
  • 刘海模式

坏人

  • SQL 理解
  • 隐式参数

丑陋的(但必要)

  • Haskell 模板
  • 未装箱的类型和元组
  • 无法确定、重叠和不连贯的实例 - 通常意味着您的设计有误。

不确定

  • 箭头符号
  • 查看模式

【讨论】:

  • 我不完全同意不可判定的实例。整体检查器非常保守,许多合理的实例声明都是不允许的。
  • 是的,这是一个折腾。我认为初学者太容易打开它,当他们应该重新设计时,它确实使某些不可能的程序成为可能。
  • SQL 理解不好,IncoherentInstances 不是?
  • @DonStewart,我想说“特定领域的语言是终极抽象”(Paul Hudak),元编程是“简单推理代码”的重要工具。
  • @SamTobin-Hochstadt 我从询问“模板 Haskell 有什么不好的地方”中得到的外卖信息问题不在于元编程难看,而是 Template Haskell 在实现安全元编程方面基本上做得不够好。我同意仔细使用元编程对于推理程序可能是一个巨大的好处,因为它允许您超越原始语言的限制,并启用更接近问题域的“语言”的表达形式。
猜你喜欢
  • 1970-01-01
  • 2019-08-05
  • 2011-03-12
  • 2013-05-19
  • 2012-07-08
  • 2016-12-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多