Type classes: an exploration of the design space
Type classes: an exploration of the design space
复制标题
类型类：设计空间的探索
DOI：
--
复制
发表时间：
1997
期刊：
影响因子：
--
通讯作者：
E. Meijer
中科院分区：
文献类型：
--
作者：
S. Jones;Mark P. Jones;E. Meijer
当类型类首次引入Haskell时，它们被认为是一种相当实验性的语言特性，因此需要相当保守的设计。从那时起，实践经验使许多程序员相信了类型类的贝内和方便。然而，有时，这些程序员也会发现，Haskell设计所施加的限制阻止了类型类重载的看似自然的应用程序。有可能以各种方式扩展Haskell的类型类机制来克服这些限制，但这些建议必须非常小心地设计。例如，几个不同的扩展已经在GARCH中实现。其中一些，特别是对多参数类的支持，已经被证明是非常有用的，但是设计的其他方面之间的交互导致了一个既不可靠又不可判定的类型系统。另一个例子是Haskell 1.3中引入的构造函数类，它没有适当地概括上下文的概念。因此，某些相当合理的程序是不可类型化的。在本文中，我们回顾了Haskell的类系统设计背后的基本原理，我们确定了当前情况下的一些弱点，并解释了我们在试图消除它们时所面临的选择。
When type classes were rst introduced in Haskell they were regarded as a fairly experimental language feature, and therefore warranted a fairly conservative design. Since that time, practical experience has convinced many programmers of the bene ts and convenience of type classes. However, on occasion, these same programmers have discovered examples where seemingly natural applications for type class overloading are prevented by the restrictions imposed by the Haskell design. It is possible to extend the type class mechanism of Haskell in various ways to overcome these limitations, but such proposals must be designed with great care. For example, several di erent extensions have been implemented in Gofer. Some of these, particularly the support for multi-parameter classes, have proved to be very useful, but interactions between other aspects of the design have resulted in a type system that is both unsound and undecidable. Another illustration is the introduction of constructor classes in Haskell 1.3, which came without the proper generalization of the notion of a context. As a consequence, certain quite reasonable programs are not typable. In this paper we review the rationale behind the design of Haskell's class system, we identify some of the weaknesses in the current situation, and we explain the choices that we face in attempting to remove them.