Int 与 Word 常用吗? [英] Int vs Word in common use?

问题描述

似乎获取/返回Int(即ByteString.hGet和Data.List.length)的常见模式与使用强描述类型的 Haskell 模式，因为其中许多情况只能处理正数.使用 Word 不是更好，还是这些函数偏向于 Int?

It seems like the common pattern of taking/returning Int (ie ByteString.hGet and Data.List.length) is contrary to the Haskell pattern of using strongly-descrbing types, since many of these cases can only handle positive numbers. Would it not be better to use Word, or is there a reason these functions are partial on Int?

推荐答案

Haskell 类型系统的表现力确实鼓励用户为他们定义的实体分配精确的类型.然而，经验丰富的 Haskells 很容易承认，必须在最终类型精度(此外，鉴于 Haskell 类型系统的当前限制，这并不总是可以实现)和便利性之间取得平衡.简而言之，精确类型仅在一定程度上有用.除此之外，它们通常只会导致额外的官僚作风，而收益甚微.

It is true that the expressiveness of the Haskell type system encourages users to assign precise types to entities they define. However, seasoned Haskellers will readily acknowledge that one must strike a balance between ultimate type precision (which besides isn't always attainable given the current limits of Haskell type system) and convenience. In short, precise types are only useful to a point. Beyond that point, they often just cause extra bureaucracy for little to no gain.

让我们用一个例子来说明这个问题.考虑阶乘函数.对于所有大于 1 的 n，n 的阶乘是偶数，而 1 的阶乘并不是很有趣，所以让我们忽略那个.因此，为了确保我们在 Haskell 中阶乘函数的实现是正确的，我们可能会尝试引入一种新的数字类型，它只能表示无符号偶数:

Let's illustrate the problem with an example. Consider the factorial function. For all n bigger than 1, the factorial of n is an even number, and the factorial of 1 isn't terribly interesting so let's ignore that one. Therefore, in order to make sure that our implementation of the factorial function in Haskell is correct, we might be tempted to introduce a new numeric type, that can only represent unsigned even integers:

module (Even) where

newtype Even = Even Integer

instance Num Even where
  ...
  fromInteger x | x `mod` 2 == 0 = Even x
                | otherwise = error "Not an even number."

instance Integral Even where
  ...
  toInteger (Even x) = x

我们将此数据类型密封在不导出构造函数的模块中，使其抽象，并使其成为 Int 是其实例的所有相关类型类的实例.现在我们可以为 factorial 提供以下签名:

We seal this datatype inside a module that doesn't export the constructor, to make it abstract, and make it an instance of the all the relevant type classes that Int is an instance of. Now we can give the following signature to factorial:

factorial :: Int -> Even

factorial 的类型肯定比我们说它返回 Int 更精确.但是你会发现用这样的类型定义 factorial 真的很烦人，因为你需要一个乘法版本，将一个(偶数或奇数)Int 与 Even 并产生 Even.更重要的是，您可能必须在客户端代码中对 factorial 调用的结果引入对 toInteger 的无关调用，这可能是造成混乱和噪音的重要来源.获得.此外，所有这些转换函数都可能对性能产生负面影响.

The type of factorial sure is more precise than if we just said that it returns Int. But you'll find that definining factorial with such a type is really quite annoying, because you need a version of multiplication that multiplies an (even or odd) Int with an Even and produces and Even. What's more, you might have to introduce extraneous calls to toInteger on the result of a call to factorial in client code, which can be a significant source of clutter and noise for little gain. Besides, all these conversion functions could potentially have a negative impact on performance.

另一个问题是，当引入一个新的、更精确的类型时，你往往最终不得不复制各种库函数.例如，如果您引入类型 List1 a 的非空列表，那么您将不得不重新实现许多 Data.List 已经提供的函数，但是对于 <仅代码>[a].当然，然后可以使这些函数成为 ListLike 类型类的方法.但是你很快就会得到各种各样的即席类型类和其他样板文件，而且收获不大.

Another problem is that when introducing a new, more precise type, you often end up having to duplicate all manner of library functions. For instance, if you introduce the type List1 a of non-empty lists, then you will have to reimplement many of the functions that Data.List already provides, but for [a] only. Sure, one can then make these functions methods of ListLike type class. But you quickly end up with all manner of adhoc type classes and other boilerplate, with again not much gain.

最后一点是，不应将 Word 视为 Int 的未签名变体.Haskell 报告留下了Int<的实际大小/code> 未指定，仅保证此类型应该能够表示范围 [− 229, 229 − 1] 内的整数.据说 Word 类型提供未指定宽度的无符号整数.不能保证在任何符合要求的实现中，Word 的宽度对应于 Int 的宽度.

One final point is that one shouldn't consider Word to be an unsigned variant of Int. The Haskell report leaves the actual size of Int unspecified, and only guarantees that this type should be capable of representing integers in the range [− 2²⁹, 2²⁹ − 1]. The type Word is said to provide unsigned integers of unspecified width. It isn't guaranteed that in any conforming implementation the width of a Word corresponds to the width of an Int.

尽管我强调要防止过度类型扩散，但我确实承认引入一种 Natural 自然类型可能会很好.然而，最终，除了 Int、Integer 和各种 Word* 类型之外，Haskell 是否应该有一个专门的自然数类型，很大程度上是品味问题.而现在的事态，很可能在很大程度上只是历史的偶然.

Though I make a point guarding against excessive type proliferation, I do acknowledge that introducing a type of Natural of naturals could be nice. Ultimately, though, whether Haskell should have a dedicated type for natural numbers, in addition to Int, Integer, and the various Word* types, is largely a matter of taste. And the current state of affairs is probably in very large part just an accident of history.

这篇关于Int 与 Word 常用吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！