Разделение классов типов и их экземпляров на разные подмодули в Haskell

Чтобы этого избежать, вы можете обернуть текст newtype

newtype FirstMonad a = FirstMonad (ReaderT (IORef String) IO a)

Но после глубокого размышления о том, что вам нужны экземпляры-сироты, вы можете подавить предупреждения:

{-# OPTIONS_GHC -fno-warn-orphans #-}

Деталь

Согласованность

Например, сейчас рассмотрим следующее определение:

data A = A

instance Eq A where
   ...

Это можно рассматривать как перегрузку на основе типов. В приведенном выше примере проверка равенства (==) может использоваться в различных типах:

f :: Eq a => a -> a -> a -> Bool
f x y z = x == y && y == z

g :: A -> A -> A -> Bool
g x y z = x == y && y == z

В определении f тип a является абстрактным и ограниченным Eq, но в g тип A является конкретным. Первый выводит метод из ограничений, но Haskell также может выводить второй. Как получить, это просто переработать Haskell в язык, который не имеет класса типов. Этот способ называется передачей по словарю.

class C a where
  m1 :: a -> a

instance C A where
  m1 x = x

f :: C a => a -> a
f = m1 . m1

Он будет преобразован:

data DictC a = DictC
  { m1 :: a -> a
  }

instDictC_A :: DictC A
instDictC_A = DictC
  { m1 = \x -> x
  }

f :: DictC a -> a -> a
f d = m1 d . m1 d

Как указано выше, сделайте так, чтобы тип данных, называемый словарем, соответствовал классу типа, и передайте значение типа.

В Haskell есть ограничение: тип не может быть объявлен как экземпляр определенного класса более одного раза в программе. Это вызывает различные проблемы.

class C1 a where
  m1 :: a

class C1 a => C2 a where
  m2 :: a -> a

instance C1 Int where
  m1 = 0

instance C2 Int where
  m2 x = x + 1

f :: (C1 a, C2 a) => a
f = m2 m1

g :: Int
g = f

Этот код использует наследование класса типа. Он выводится в соответствии с разработанным кодом.

  { m1 :: a
  }

data DictC2 a = DictC2
  { superC1 :: DictC1 a
  , m2 :: a -> a
  }

instDictC1_Int :: DictC1 Int
instDictC1_Int = DictC1
  { m1 = 0
  }

instDictC2_Int :: DictC2 Int
instDictC2_Int = DictC2
  { superC1 = instDictC1_Int
  , m2 = \x -> x + 1
  }

f :: DictC1 a -> DictC2 a -> a
f d1 d2 = ???

g :: Int
g = f instDictC1_Int instDictC2_Int

Хорошо, какое определение для f происходит? На самом деле определения следующие:

f :: DictC1 a -> DictC2 a -> a
f d1 d2 = m2 d2 (m1 d1)

f :: DictC1 a -> DictC2 a -> a
f _ d2 = m2 d2 (m1 d1)
  where
    d1 = superC1 d2

Вы подтверждаете, что у него нет проблем с набором текста? Если Haskell может повторно определить Int как экземпляр C1, superC1 в DictC2 будет заполнено уточнением, значение, вероятно, будет отличаться от DictC1 a, переданного в f при вызове g.

Давайте посмотрим еще пример:

h :: (Int, Int)
h = (m1, m1)

Конечно, проработка одна:

h :: (Int, Int)
h = (m1 instDictC1_Int, m1 instDictC1_Int)

Но если можно повторно определить экземпляр, можно также рассмотреть следующую разработку:

h :: (Int, Int)
h = (m1 instDictC1_Int, m1 instDictC1_Int')

Следовательно, два одинаковых типа применяются в двух разных экземплярах. Например, вызов одной и той же функции дважды, но, возможно, возвращает другое значение по другому алгоритму.

Приведенный пример немного преувеличен, но как насчет следующего примера?

instance C1 Int where
  m1 = 0

h1 :: Int
h1 = m1

instance C1 Int where
  m1 = 1

h2 :: (Int, Int)
h2 = (m1, h1)

В этом случае вполне возможно использовать разные экземпляры m1 в h1 и m1 в h2. Haskell часто предпочитает преобразование, основанное на рассуждениях по уравнениям, поэтому проблема заключается в том, что h1 нельзя заменить напрямую на m1.

Как правило, система типов включает разрешение экземпляров классов типов. В таком случае разрешайте экземпляры при проверке типов. А коды разрабатываются по дереву вывода, составленному при проверке типов. Такое преобразование иногда адаптируется помимо класса типа, в частности, неявного преобразования типа, типа записи и т.д. Затем эти случаи, возможно, вызывают проблему, как указано выше. Эту задачу можно формализовать следующим образом:

При преобразовании дерева вывода типа в язык в двух разных деревьях вывода одного типа результаты преобразования не становятся семантически эквивалентными.

Как уже говорилось, даже применяйте любой экземпляр, соответствующий типу, и, как правило, он должен пройти проверку типа. Однако результат обработки с использованием экземпляра, возможно, отличается от результата обработки после разрешения другого экземпляра. Наоборот, если у вас нет этой проблемы, вы можете получить определенную гарантию системы типов. Эта гарантия, сочетание системы типов, на которую не работает формализованная выше проблема, и свойства разработки, обычно называется когерентностью. Есть некоторый способ гарантировать согласованность, Haskell ограничивает количество определений экземпляров, соответствующих классу типов, до одного, чтобы гарантировать согласованность.

Бесхозный экземпляр

Легко сказать, как работает Haskell, но есть некоторые проблемы. Довольно известным является экземпляр-сирота. GHC, в объявлении типа T как экземпляре C обработка экземпляра зависит от того, находится ли объявление в том же модуле, в котором есть объявление T или C. В частности, не в том же модуле, который называется потерянным экземпляром, предупредит GHC. Почему, как это работает?

Во-первых, в Haskell экземпляры неявно распространяются между модулями. Это оговаривается следующим образом:

Все экземпляры в пределах модуля всегда экспортируются, и любой импорт приносит все экземпляры из импортированного модуля. Таким образом, объявление экземпляра находится в области видимости тогда и только тогда, когда цепочка объявлений импорта ведет к модулю, содержащему объявление экземпляра. --5 модулей

Мы не можем остановить это, не можем это контролировать. Во-первых, Haskell решил позволить нам определять один тип как один экземпляр, так что об этом не нужно думать. Кстати, хорошо, что есть такой регламент, на самом деле компилятор Haskell должен разрешать экземпляры в соответствии с регламентом. Конечно, компилятор не знает, какие модули имеют экземпляры, в худшем случае он должен проверять все модули. Нас это тоже смущает. Если два важных модуля привязывают каждое определение экземпляра к одному и тому же типу, все модули, цепочки импорта которых включают модули, становятся недоступными из-за конфликта.

Что ж, чтобы использовать тип как экземпляр класса, нам нужна информация о них, поэтому мы перейдем к модулю, в котором есть объявления. Тогда не произойдет того, что третья сторона возится с модулем. Поэтому, если какой-либо из модулей включает объявление экземпляра, компилятор может видеть необходимую информацию с экземплярами, мы рады, что включение загрузки модулей гарантирует отсутствие конфликтов. По этой причине рекомендуется тип как экземпляр класса, помещенный в тот же модуль, который имеет объявление типа или класса. Наоборот, рекомендуется избегать экземпляров-сирот, насколько это возможно. Следовательно, если вы хотите создать тип как независимый экземпляр, создайте новый тип с помощью newtype, чтобы изменить только семантику экземпляра, объявив тип как экземпляр.

Кроме того, GHC помечает внутренние модули как экземпляры-сироты, а экземпляры-сироты модулей перечисляются в файлах интерфейса их зависимых модулей. И тогда компилятор ссылается на весь список. Таким образом, чтобы один раз сделать потерянный экземпляр, файл интерфейса модуля, который имеет экземпляр, когда все модули зависят от перекомпиляции модуля, будет перезагружен, если что-то изменится. Таким образом, экземпляр-сирота плохо влияет на время компиляции.

Деталь находится под CC BY-SA 4.0 (C) Мизунаси Мана

Оригинал 続くといいな日記 – 型クラスの Coherence と Orphan Instance

22.12.2020 отредактировано и переведено Акихито Кирисаки