为什么Haskell不能在函数签名中推断数据类型的类型类? [英] Why does Haskell stop short of inferring the datatype's typeclasses in the function signatures?

问题描述

首先，这个问题并非100％针对Haskell，请随意评论类型类，接口和类型的一般设计.

Firstly, this question isn't 100% specific to Haskell, feel free to comment on the general design of typeclasses, interfaces and types.

我正在阅读 LYAH-创建类型和类型类我正在寻找有关以下内容的文章:

I'm reading LYAH - creating types and typeclasses The following is the passage that I'm looking for more information on:

Data (Ord k) => Map k v = ...  

但是，这是一个非常严格的约定 在Haskell中永远不要添加typeclass 数据声明中的约束.为什么? 好吧，因为我们受益不多， 但是我们最终要写更多的课 约束，即使我们不需要 他们.如果我们放置或不放置Ord k 数据声明中的约束 映射k v，我们将不得不放 功能的约束 假设地图中的键可以是 下令.但是，如果我们不把 数据声明中的约束，我们 不必将(Ord k)=>放入 类型声明的功能 不在乎按键是否可以 是否订购.这样的例子 函数是toList，只需要一个 映射并将其转换为 关联列表.其类型签名 是toList :: Map k a-> [(k，a)].如果 映射k v在其类型中具有类型约束 数据声明，toList的类型 将必须是toList ::(Ord k)=> 映射k a-> [(k，a)]，即使 函数不做任何比较 按键顺序.

However, it's a very strong convention in Haskell to never add typeclass constraints in data declarations. Why? Well, because we don't benefit a lot, but we end up writing more class constraints, even when we don't need them. If we put or don't put the Ord k constraint in the data declaration for Map k v, we're going to have to put the constraint into functions that assume the keys in a map can be ordered. But if we don't put the constraint in the data declaration, we don't have to put (Ord k) => in the type declarations of functions that don't care whether the keys can be ordered or not. An example of such a function is toList, that just takes a mapping and converts it to an associative list. Its type signature is toList :: Map k a -> [(k, a)]. If Map k v had a type constraint in its data declaration, the type for toList would have to be toList :: (Ord k) => Map k a -> [(k, a)], even though the function doesn't do any comparing of keys by order.

乍一看，这似乎是合乎逻辑的-但是将typeclass附加到类型上并没有好处吗?如果类型类是类型的行为，那么为什么应该通过使用类型(通过函数)而不是类型本身来定义行为呢?我假设有一些可以利用它的元编程，它当然是不错的描述性代码文档.相反，用其他语言，这会是一个好主意吗?在对象上指定对象应符合的接口是否理想，这样，如果调用方未使用该方法，则对象不必符合该接口?而且，为什么Haskell不能推断使用Foo类型的函数必须引入在Foo类型的声明中标识的类型类约束?是否有启用此功能的实用程序?

This at first, seems logical -- but isn't there an upside to having the typeclass attached to the type? If the typeclass is the behavior of the type, then why should the behavior be defined by the use of the type (through functions), and not the type itself? I assume there is some meta-programming that could make use of it, and it is certainly nice and descriptive code-documentation. Conversely, would this be a good idea in other languages? Would it be ideal to specify the interface the object should conform to on the method, such that if the method isn't used by the caller the object doesn't have to conform to the interface? Moreover, why can Haskell not infer that a function using type Foo, has to pull in the typeclass constraints identified in type Foo's declaration? Is there a pragma to enable this?

我第一次阅读它时，它想到的是这是一个hack(或解决方法)响应".经过重新思考后，听起来很聪明.经过三读，对OO世界产生了厌恶，这听起来又像是黑客.

The first time I read it, it conjured a "that's a hack (or workaround) response". On second read with some thought, it sounded clever. On third read, drawing a compairison to the OO world, it sounded like a hack again.

我在这里.

推荐答案

也许Map k v并不是说明这一点的最佳示例.给定Map的定义，即使有些函数不需要(Ord k)约束，但如果没有Map的话，也无法构建Map.

Perhaps Map k v wasn't the best example to illustrate the point. Given the definition of Map, even though there are some functions that won't need the (Ord k) constraint, there is no possible way to construct a Map without it.

人们经常发现，即使将约束视为原始设计的明显方面，类型也可以在没有特定约束的情况下与功能的子集一起使用.在这种情况下，取消类型声明的约束会使它更加灵活.

One often finds that a type is quite usable with the sub-set of functions that work on without some particular constraint, even when you envisioned the constraint as an obvious aspect of your original design. In such cases, having left the constraint off the type declaration leaves it more flexible.

例如，Data.List包含许多需要(Eq a)的功能，但是当然，在没有该约束的情况下，列表非常有用.

For example, Data.List contains plenty of functions that require (Eq a), but of course lists are perfectly useful without that constraint.

这篇关于为什么Haskell不能在函数签名中推断数据类型的类型类?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！