Int vs Word В общем использовании?

верно, что выразительность системы типов Haskell побуждает пользователей назначать точные типы сущностям, которые они определяют. Однако опытные Хаскеллеры с готовностью признают, что необходимо соблюдать баланс между предельной точностью типа (которая, кроме того, не всегда достижима, учитывая текущие пределы системы типа Haskell) и удобством. Короче говоря, точные типы полезны только в определенной степени. За пределами этого момента они часто просто вызывают дополнительную бюрократию для little to no прибыль.

проиллюстрируем проблему на примере. Рассмотрим факторную функцию. Для всех n больше 1, факториал n является четным числом,и факториал 1 не очень интересен, поэтому давайте проигнорируем это. Поэтому, чтобы убедиться, что наша реализация факториальной функции в Haskell верна, у нас может возникнуть соблазн ввести новый числовой тип, который может представлять только беззнаковые четные целые числа:

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 :: Int -> Even

тип factorial конечно, более точно, чем если бы мы просто сказали, что он возвращает Int. Но вы найдете, что Defining factorial С таким типом действительно довольно раздражает, потому что вам нужна версия умножения, которая умножает (четное или нечетное)Int С Even производит и Even. Более того, вам может потребоваться ввести посторонние вызовы toInteger в результате вызова factorial в коде клиента, который может быть значительным источником помех и шумов мало приобрести. Кроме того, все эти функции преобразования потенциально могут оказать негативное влияние на производительность.

другая проблема заключается в том, что при введении нового, более точного типа вам часто приходится дублировать всевозможные библиотечные функции. Например, если ввести тип List1 a непустых списков, то вам придется переопределить многие из функций, которые Data.List уже обеспечивает, но для [a] только. Конечно, можно затем сделать эти методы функций ListLike тип класса. Но вы быстро заканчиваете все виды классов типа adhoc и других шаблонных, с снова не большим выигрышем.

последний момент заключается в том, что не следует рассматривать Word быть неподписанным вариант Int. The отчет Хаскелл оставляет фактический размер Int не указано, и только гарантирует, что этот тип должен быть способен представлять целые числа в диапазоне [- 2²⁹, 2²⁹ - 1]. Тип Word написано целых чисел без знака неуказанной ширину. Не гарантируется, что в любой соответствующей реализации ширина a Word соответствует ширине Int.

хотя я защищая от чрезмерного распространения типа, Я признаю, что введение типа Natural из naturals может быть хорошо. В конечном счете, однако, должен ли Haskell иметь выделенный тип для натуральных чисел, в дополнение к Int, Integer, и различных Word* типы, в основном это вопрос вкуса. И нынешнее положение дел, вероятно, в значительной степени является просто случайностью истории.