Haskell: дублированные функции (+) и (++), mappend

Ответ 1

Здесь вы пытаетесь смешивать несколько отдельных понятий.

Арифметика и конкатенация списков - очень практичные, прямые операции. Если вы пишете:

[1, 2] ++ [3, 4]

... вы знаете, что в результате вы получите [1, 2, 3, 4].

A Monoid - математическое алгебраическое понятие, которое находится на более абстрактном уровне. Это означает, что mappend не означает, что буквально означает "добавить это к этому"; он может иметь много других значений. Когда вы пишете:

[1, 2] `mappend` [3, 4]

... это некоторые достоверные результаты, которые может произвести эта операция:

[1, 2, 3, 4] -- concatenation, mempty is []

[4, 6]       -- vector addition with truncation, mempty is [0,0..]

[3, 6, 4, 8] -- some inner product, mempty is [1]

[3, 4, 6, 8] -- the cartesian product, mempty is [1]

[3, 4, 1, 2] -- flipped concatenation, mempty is []

[]           -- treating lists like `Maybe a`, and letting lists that
             -- begin with positive numbers be `Just`s and other lists
             -- be `Nothing`s, mempty is []

Почему mappend для списков просто объединяет списки? Потому что это просто определение для моноидов, что ребята, которые написали Haskell Report, выбрали в качестве реализации по умолчанию, вероятно, потому, что это имеет смысл для всех типов элементов списка. И действительно, вы можете использовать альтернативный экземпляр Monoid для списков путем их переноса в различные типы newtypes; существует, например, альтернативный экземпляр Monoid для списков, которые выполняют на них декартовы произведения.

Понятие "моноид" имеет фиксированное значение и долгую историю в математике, и изменение его определения в Haskell означает отклонение от математической концепции, которой не должно быть. Моноид - это не просто описание пустого элемента и операции (добавление/конкатенация); это основа для широкого спектра концепций, которые соответствуют интерфейсу, который предоставляет Monoid.

Концепция, которую вы ищете, специфична для чисел (потому что вы не можете определить что-то вроде mmultiply или, возможно, mproduce/mproduct для всех экземпляров Maybe a, например), концепция, которая уже существует и называется Semiring в математике (ну, вы действительно не рассматривали ассоциативность в своем вопросе, но вы прыгаете между различными понятиями в ваши примеры в любом случае "иногда придерживаются ассоциативности, иногда нет", но общая идея такая же).

В Haskell уже реализованы реализации Semirings, например, в пакете algebra.

Однако моноид не является, как правило, Semiring, а также есть несколько реализаций Semirings для действительных чисел, кроме, в частности, добавления и умножения. Добавление широких обобщенных дополнений к очень четким типам классов, таких как Monoid, не должно выполняться только потому, что оно "было бы аккуратным" или "сэкономило бы несколько нажатий клавиш"; есть причина, по которой мы имеем (++), (+) и mappend как отдельные понятия, потому что они представляют собой совершенно разные вычислительные идеи.

Ответ 2

При переименовании mappend на (+)/(*)

В то время как (+) и (*) являются моноидами, они имеют дополнительные законы распределения, относящиеся к двум операциям, а также законы отмены, например. 0 * x = 0. По существу, (+) и (*) образуют ring. Две моноиды на каком-то другом типе могут не удовлетворять этим кольцам (или даже более слабым полукольцевым) свойствам. Именование операторов (+) и (*) указывает на их дополнительные (взаимосвязанные) свойства. Таким образом, я бы избегал подрывать традиционные математические интуиции, переименовывая mappend в + или *, поскольку эти имена предполагают дополнительные свойства, которые могут не выполняться. Иногда слишком много перегрузки (т.е. Слишком много обобщений) приводит к потере интуиции и, следовательно, к снижению удобства использования.

Если у вас есть две моноиды, которые образуют какое-то кольцо, вам может понадобиться извлечь из него экземпляр Num, так как имена "+" и "*" предполагают дополнительные свойства.

В conflating (++) и mappend

Переименование mappend в (++) может быть более уместным, так как с помощью (++) существует меньший дополнительный ментальный багаж. Действительно, поскольку списки являются свободным моноидом (то есть моноидом без дополнительных свойств), то использование традиционного оператора списка-конкатенации (++) для обозначения бинарной операции моноида не кажется страшной идеей.

При определении нескольких моноидов для одного типа

Как вы указываете, обе (+) являются (*) являются моноидами, но оба нельзя сделать экземпляром Monoid для того же типа t. Одним из решений, которое вы получаете наполовину, является наличие дополнительного параметра типа для класса Monoid для выделения двух моноидов. Обратите внимание, что классы типов могут быть параметризированы только типами, а не выражением, которое вы укажете в своем вопросе. Подходящим определением будет что-то вроде:

class Monoid m variant where
 mappend :: variant -> m -> m -> m
 mempty :: variant -> m

data Plus = Plus
data Times = Times

instance Monoid Int Plus where
    mappend Plus x y = x `intPlus` y
    mempty = 0

instance Monoid Int Times where
    mappend Times x y = x `intTimes` y
    mempty = 1

(+) = mappend Plus
(*) = mappend Times 

Чтобы приложения mappend/mempty были разрешены для конкретной операции, каждый должен принять значение, свидетельствующее тип, указывающий конкретный моноидный "вариант".

Кроме того, в названии вашего вопроса упоминается mconcat. Это совершенно другая операция с mappend - mconcat является моноидным гомоморфизмом из свободного моноида в какой-либо другой моноид, т.е. Заменяет cons на mappend и nil на mempty.

Ответ 3

Если вы посмотрите на Hackage, вы найдете много альтернатива Prelude реализация в исправление эти проблемы.

Ответ 4

Ну есть две моноиды для чисел - Product и Sum, как бы вы справились с этим?

Три и, возможно, больше, функции для одного и того же, не очень хорошо для красивого языка, который настаивает на абстракции и таких вещах, как Haskell.

Абстракции не касаются устранения дублирования кода. Арифметические и моноидные операции - это две разные идеи, и, несмотря на то, что они имеют одну и ту же семантику, вы ничего не получаете, объединяя их.