Haskell类型系统评估与依赖类型的探索
1. Haskell类型系统的优缺点及80/20规则
在编程语言设计中,类型系统的设计是一种平衡行为,既要追求表达能力(自由表达有趣的事物),又要保留一定的自动化、易用性和概念一致性,而这两者很难兼得。不过,Haskell在这方面取得了不错的平衡。
Haskell的类型系统相当灵活,只有在使用复杂重载时才需要显式提示。然而,它也有一些局限性。比如,传统面向对象编程(OOP)中的一些特性在Haskell中难以实现,主要是构建无限制混合类型对象列表(“异构列表”)的能力,在标准Haskell中无法编写像 [2, 'a', False] 这样的代码。不过,有一些扩展可以支持此类列表的各种情况,但各有优缺点。如果提前知道预期的类型,我们可以将其编码为标记联合并自行解码,也可以采用将值简化为公共接口的技术。
这里可以引入80/20规则。根据经验,与主流编程语言相比,超过80%的代码可以很好地在Haskell中实现,剩下的部分也不会带来太大困扰,并非不可接受。因此,我们应该享受那80%部分带来的便利和好处,容忍一小部分代码的不便。从工程角度看,仅仅因为程序中少数部分的问题而放弃80%部分的优势,转而使用动态语言是不明智的。这个规则同样适用于Haskell的编程方面,超过80%的代码可以在纯函数式环境中良好运行,麻烦的部分不到20%,而且通常更少。
这对动态类型意味着什么呢?Haskell及其相关语言正逐渐达到一种灵活性和不干扰性的水平,成为一种可靠的选择。许多传统上对静态类型的反对意见和对动态类型的传统辩护开始失去说服力,需要重新评估。有些反对意见比较模糊,例如从Java的结论推断Haskell。最
超级会员免费看
订阅专栏 解锁全文
8

被折叠的 条评论
为什么被折叠?



