Кто первым сказал следующее?

Монада - это просто моноид в категории эндофункторов, в чем проблема?

И на менее важной ноте, правда ли это, и если да, то могли бы вы дать объяснение (надеюсь, что оно может быть понято кем-то, кто не имеет большого опыта в Haskell)?

Эта конкретная фраза написана Джеймсом Ири из его очень интересной « Краткой, неполной и в основном неправильной истории языков программирования» , в которой он вымышленно приписывает ее Филиппу Уодлеру.

Оригинальная цитата написана Сондерсом Мак Лейном в разделе «Категории для рабочего математика» , одного из основополагающих текстов теории категорий. Здесь это в контексте , который, вероятно, является лучшим местом, чтобы узнать, что именно это означает.

Но я сделаю удар. Оригинальное предложение таково:

В общем, монада в X - это просто моноид в категории эндофункторов X, с произведением ×, замененным композицией эндофункторов и единицей, установленной единичным эндофунктором.

Х здесь есть категория. Endofunctors функторы из категории в себе (что, как правило , все Functor -е, насколько функциональные программисты обеспокоены, так как они в основном имеет дело только с одной категорией; категория типов - но я отвлекся). Но вы можете представить себе другую категорию, которая относится к категории «эндофункторы на X ». Это категория, в которой объекты являются эндофункторами, а морфизмы - естественными преобразованиями.

И из этих эндофункторов, некоторые из них могут быть монадами. Какие из них монады? Именно те, которые являются моноидальными в определенном смысле. Вместо того, чтобы описать точное отображение от монад к моноидам (поскольку Mac Lane делает это намного лучше, чем я мог надеяться), я просто добавлю их соответствующие определения рядом и позволю вам сравнить:

Моноид это ...

• Набор, С
• Операция, •: S × S → S
• Элемент S , e: 1 → S

... удовлетворяя этим законам:

• (a • b) • c = a • (b • c) , для всех a , b и c в S
• е • а = а • е = а , для всех а в S

Монада это ...

• Endofunctor, T: X → X (в Haskell, конструктор типов * -> *с Functorэкземпляром)
• Естественное преобразование, μ: T × T → T , где × означает композицию функтора ( μ известен как joinв Haskell)
• Естественное преобразование, η: I → T , где I - единичный эндофунктор на X ( η известно как returnв Хаскеле)

... удовлетворяя этим законам:

• μ ∘ Tμ = μ ∘ μT
• μ ∘ Tη = μ ∘ ηT = 1 (тождественное естественное преобразование)

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

Интуитивно, я думаю, что сказочный математический словарь говорит о том, что:

Monoid

Моноид представляет собой набор объектов, а также способ их объединения. Хорошо известны моноиды:

• числа, которые вы можете добавить
• списки, которые вы можете объединить
• наборы, которые вы можете объединить

Есть и более сложные примеры.

Кроме того, у каждого моноида есть идентичность , то есть тот элемент «без операции», который не действует, когда вы комбинируете его с чем-то другим:

• 0 + 7 == 7 + 0 == 7
• [] ++ [1,2,3] == [1,2,3] ++ [] == [1,2,3]
• {} union {apple} == {apple} union {} == {apple}

Наконец, моноид должен быть ассоциативным . (вы можете уменьшить длинную строку комбинаций в любом случае, если только вы не измените порядок объектов слева направо). Дополнение в порядке ((5 + 3) +1 == 5+ (3+ 1)), но вычитание не ((5-3) -1! = 5- (3-1)).

монада

Теперь давайте рассмотрим особый вид множества и особый способ объединения объектов.

Объекты

Предположим, что ваш набор содержит объекты специального вида: функции . И эти функции имеют интересную сигнатуру: они не переносят числа в числа или строки в строки. Вместо этого каждая функция переносит число в список чисел в двухэтапном процессе.

1. Вычислить 0 или более результатов
2. Объедините эти результаты в один ответ как-нибудь.

Примеры:

• 1 -> [1] (просто оберните ввод)
• 1 -> [] (отменить ввод, обернуть небытие в списке)
• 1 -> [2] (добавьте 1 к входу и оберните результат)
• 3 -> [4, 6] (добавить 1 к вводу, умножить ввод на 2 и обернуть несколько результатов )

Объединение объектов

Кроме того, наш способ объединения функций является особенным. Простой способ объединить функцию - это композиция : давайте возьмем наши примеры выше и скомпонуем каждую функцию с собой:

• 1 -> [1] -> [[1]] (дважды обернуть вход)
• 1 -> [] -> [] (отменить ввод, обернуть пустоту в списке, дважды)
• 1 -> [2] -> [UH-OH! ] (мы не можем «добавить 1» в список! »)
• 3 -> [4, 6] -> [UH-OH! ] (мы не можем добавить 1 список!)

Не слишком углубляясь в теорию типов, дело в том, что вы можете объединить два целых числа, чтобы получить целое число, но вы не всегда можете составить две функции и получить функцию одного типа. (Функции с типом a -> a будут составлять, но a-> [a] не будут.)

Итак, давайте определим другой способ объединения функций. Когда мы объединяем две из этих функций, мы не хотим «оборачивать» результаты.

Вот что мы делаем. Когда мы хотим объединить две функции F и G, мы следуем этому процессу (называемому привязкой ):

1. Вычислите «результаты» из F, но не объединяйте их.
2. Вычислите результаты применения G к каждому из результатов F по отдельности, получая коллекцию результатов.
3. Сгладьте 2-уровневую коллекцию и объедините все результаты.

Возвращаясь к нашим примерам, давайте объединим (свяжем) функцию с самой собой, используя этот новый способ «связывания» функций:

• 1 -> [1] -> [1] (дважды обернуть вход)
• 1 -> [] -> [] (отменить ввод, обернуть пустоту в списке, дважды)
• 1 -> [2] -> [3] (добавьте 1, затем снова добавьте 1 и оберните результат.)
• 3 -> [4,6] -> [5,8,7,12] (добавьте 1 к вводу, а также умножьте ввод на 2, сохраняя оба результата, затем сделайте все снова для обоих результатов, а затем оберните окончательный вариант результаты в списке.)

Этот более сложный способ объединения функций является ассоциативным (следуя тому, как составление функций ассоциативно, когда вы не делаете причудливую упаковку).

Связывая все это вместе,

• Монада - это структура, которая определяет способ объединения (результатов) функций,
• аналогично тому, как моноид является структурой, которая определяет способ объединения объектов,
• где метод комбинации является ассоциативным,
• и где есть специальное «неоперативное», которое может быть объединено с чем-то, что приведет к чему-то неизменному.

Ноты

Есть много способов «обернуть» результаты. Вы можете создать список, или набор, или отбросить все, кроме первого результата, отметив, что результатов нет, прикрепить коляску состояний, распечатать сообщение журнала и т. Д. И т. Д.

Я немного расстроился с определениями в надежде донести основную идею до интуитивно понятной.

Я немного упростил ситуацию, настаивая на том, что наша монада работает с функциями типа a -> [a] . На самом деле, монады работают с функциями типа a -> mb , но обобщение - это своего рода техническая деталь, которая не является основным понятием.

Во-первых, расширения и библиотеки, которые мы собираемся использовать:

{-# LANGUAGE RankNTypes, TypeOperators #-}

import Control.Monad (join)

Из них RankNTypesединственный, который абсолютно необходим для нижеследующего. Однажды я написал объяснение того, RankNTypesчто некоторые люди считают полезным , поэтому я буду ссылаться на это.

Цитируя отличный ответ Тома Крокетта , мы имеем:

Монада это ...

• Эндофунктор, T: X -> X
• Естественное преобразование, μ: T × T -> T , где × означает композицию функтора.
• Естественное преобразование η: I -> T , где I - единичный эндофунктор на X

... удовлетворяя этим законам:

• μ (μ (T × T) × T)) = μ (T × μ (T × T))
• μ (η (T)) = T = μ (T (η))

Как мы можем перевести это на код на Haskell? Что ж, давайте начнем с понятия естественной трансформации :

-- | A natural transformations between two 'Functor' instances.  Law:
--
-- > fmap f . eta g == eta g . fmap f
--
-- Neat fact: the type system actually guarantees this law.
--
newtype f :-> g =
    Natural { eta :: forall x. f x -> g x }

Тип формы f :-> gаналогичен типу функции, но вместо того, чтобы думать о ней как о функции между двумя типами (типа *), думать о ней как о морфизме между двумя функторами (каждый из которых является родом * -> *). Примеры:

listToMaybe :: [] :-> Maybe
listToMaybe = Natural go
    where go [] = Nothing
          go (x:_) = Just x

maybeToList :: Maybe :-> []
maybeToList = Natural go
    where go Nothing = []
          go (Just x) = [x]

reverse' :: [] :-> []
reverse' = Natural reverse

По сути, в Haskell естественные преобразования - это функции из f xодного типа в другой g x, так что xпеременная типа «недоступна» для вызывающей стороны. Так, например, sort :: Ord a => [a] -> [a]нельзя превратить в естественную трансформацию, потому что она «требовательна» к тому, для каких типов мы можем создавать экземпляры a. Один интуитивный способ, которым я часто пользуюсь, чтобы думать об этом, заключается в следующем:

• Функтор - это способ оперировать содержимым чего-либо, не касаясь структуры .
• Естественная трансформация - это способ воздействовать на структуру чего-либо, не касаясь и не глядя на содержание .

Теперь, со всем этим, давайте рассмотрим пункты определения.

Первый пункт - это «endofunctor, T: X -> X ». Ну, каждый Functorв Haskell является эндофунктором в том, что люди называют «категорией Hask», чьи объекты являются типами Haskell (вида *) и чьи морфизмы являются функциями Haskell. Это звучит как сложное утверждение, но на самом деле оно очень тривиально. Все это означает, что a Functor f :: * -> *дает вам возможность создать тип f a :: *для любого a :: *и функцию fmap f :: f a -> f bиз любого f :: a -> b, и что они подчиняются законам функторов.

Второе предложение: Identityфунктор в Haskell (который поставляется с платформой, так что вы можете просто импортировать его) определяется следующим образом:

newtype Identity a = Identity { runIdentity :: a }

instance Functor Identity where
    fmap f (Identity a) = Identity (f a)

Таким образом, естественное преобразование η: I -> T из определения Тома Крокетта может быть записано так для любого Monadслучая t:

return' :: Monad t => Identity :-> t
return' = Natural (return . runIdentity)

Третье предложение: состав двух функторов в Haskell может быть определен следующим образом (который также поставляется с платформой):

newtype Compose f g a = Compose { getCompose :: f (g a) }

-- | The composition of two 'Functor's is also a 'Functor'.
instance (Functor f, Functor g) => Functor (Compose f g) where
    fmap f (Compose fga) = Compose (fmap (fmap f) fga)

Поэтому естественное преобразование μ: T × T -> T из определения Тома Крокетта можно записать так:

join' :: Monad t => Compose t t :-> t
join' = Natural (join . getCompose)

Утверждение, что это моноид в категории эндофункторов, означает, что Compose(частично примененное только к его первым двум параметрам) является ассоциативным, и это Identityявляется его единичным элементом. Т.е. справедливы следующие изоморфизмы:

• Compose f (Compose g h) ~= Compose (Compose f g) h
• Compose f Identity ~= f
• Compose Identity g ~= g

Это очень легко доказать , потому что Composeи Identityоба определены как newtype, и Haskell отчеты определяют семантикуnewtype как изоморфизм между типом определяется и тип аргумента newtypeконструктора «ы данных. Итак, например, давайте докажем Compose f Identity ~= f:

Compose f Identity a
    ~= f (Identity a)                 -- newtype Compose f g a = Compose (f (g a))
    ~= f a                            -- newtype Identity a = Identity a
Q.E.D.

Примечание: нет, это не правда. В какой-то момент был дан комментарий к этому ответу от самого Дана Пипони, в котором говорилось, что причина и следствие здесь были совершенно противоположными, что он написал свою статью в ответ на шутку Джеймса Ири. Но, похоже, он был удален, возможно, каким-то навязчивым тидиром.

Ниже мой оригинальный ответ.

Вполне возможно, что Ири прочитал статью « От моноидов к монадам» - пост, в котором Дэн Пипони (sigfpe) выводит монады из моноидов в Хаскеле, с большим обсуждением теории категорий и явным упоминанием «категории эндофункторов на Хаске ». В любом случае, любой, кто интересуется, что значит монада в категории эндофункторов, может извлечь пользу из прочтения этого вывода.

Я пришел к этому посту, чтобы лучше понять вывод печально известной цитаты из « Теории категорий Мак Лэйна для рабочего математика» .

При описании того, что является чем-то, часто одинаково полезно описать, что это не так.

Тот факт, что Mac Lane использует описание для описания монады, можно предположить, что она описывает нечто уникальное для монад. Потерпите меня. Чтобы развить более широкое понимание заявления, я полагаю, что необходимо дать понять, что он не описывает нечто уникальное для монад; утверждение одинаково описывает Аппликатив и Стрелки среди других. По той же причине у нас может быть два моноида на Int (Sum и Product), у нас может быть несколько моноидов на X в категории эндофункторов. Но есть еще больше сходства.

И Monad, и Applicative соответствуют критериям:

• endo => любая стрелка или морфизм, который начинается и заканчивается в одном и том же месте
• functor => любая стрелка или морфизм между двумя категориями

  (например, изо дня в день Tree a -> List b, но в категории Tree -> List)

• моноид => один объект; т. е. один тип, но в этом контексте только в отношении внешнего уровня; Итак, мы не можем иметь Tree -> List, только List -> List.

В операторе используется «Категория ...» Это определяет область действия оператора. В качестве примера Категория Functor описывает область действия f * -> g *, Any functor -> Any functorнапример, Tree * -> List *или Tree * -> Tree *.

То, что категорическое утверждение не указывает, описывает, где что-либо и все разрешено .

В этом случае внутри функторов * -> *aka a -> bне указано, что означает Anything -> Anything including Anything else. Когда мое воображение переходит к Int -> String, оно также включает Integer -> Maybe Intили даже Maybe Double -> Either String Intгде a :: Maybe Double; b :: Either String Int.

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

• область действия функтора :: f a -> g b(т. е. любой параметризованный тип для любого параметризованного типа)
• endo + функтор :: f a -> f b(т. е. любой один параметризованный тип к тому же параметризованному типу) ... по-другому,
• моноид в категории эндофунктор

Итак, где же сила этой конструкции? Чтобы оценить всю динамику, мне нужно было увидеть, что типичные рисунки моноида (один объект с чем-то вроде стрелки-идентификатора :: single object -> single object) не иллюстрируют, что мне разрешено использовать стрелку, параметризованную любым количеством значений моноидов, из объекта одного типа, разрешенного в Monoid. Определение эквивалентности стрелки endo, ~ identity игнорирует значение типа функтора, а также тип и значение самого внутреннего слоя «полезной нагрузки». Таким образом, эквивалентность возвращается trueв любой ситуации, когда совпадают функторные типы (например, Nothing -> Just * -> Nothingэквивалентно тому, Just * -> Just * -> Just *что они оба Maybe -> Maybe -> Maybe).

Боковая панель: ~ снаружи является концептуальным, но является самым левым символом в f a. Он также описывает, что «Хаскелл» читает первым (большая картина); так что тип "снаружи" по отношению к значению типа. Взаимосвязь между слоями (цепочкой ссылок) в программировании нелегко установить в категории. Категория набора используется для описания типов (Int, Strings, Maybe Int и т. Д.), Которые включают в себя категорию функторов (параметризованные типы). Цепочка ссылок: тип функтора, значения функтора (элементы набора этого функтора, например, Nothing, Just) и, в свою очередь, все остальное, на которое указывает каждое значение функтора. В категории отношения описываются по-разному, например, return :: a -> m aсчитается естественным преобразованием одного функтора в другой, отличным от всего, что упоминалось до сих пор.

Возвращаясь к основному потоку, в общем, для любого определенного тензорного произведения и нейтрального значения, в итоге утверждение описывает удивительно мощную вычислительную конструкцию, порожденную ее парадоксальной структурой:

• снаружи он выглядит как единый объект (например, :: List); статический
• но внутри, допускает много динамики
  • любое количество значений того же типа (например, Empty | ~ NonEmpty), что и fodder для функций любой арности. Тензорный продукт уменьшит любое количество входных данных до единого значения ... для внешнего уровня (~ foldкоторый ничего не говорит о полезной нагрузке)
  • бесконечный диапазон как типа, так и значений для самого внутреннего слоя

В Haskell важно уточнить применимость этого утверждения. Мощь и универсальность этой конструкции не имеет абсолютно никакого отношения к монаде как таковой . Другими словами, конструкция не полагается на то, что делает монаду уникальной.

При попытке выяснить, следует ли создавать код с общим контекстом для поддержки вычислений, которые зависят друг от друга, по сравнению с вычислениями, которые могут выполняться параллельно, это печально известное утверждение, как бы оно ни описывалось, не является контрастом между выбором Аппликатив, Стрелы и Монады, а скорее это описание того, насколько они одинаковы. Для данного решения утверждение является спорным.

Это часто неправильно понимают. Утверждение далее описывается join :: m (m a) -> m aкак тензорное произведение для моноидального эндофунктора. Однако в нем не сформулировано, как в контексте этого утверждения (<*>)также можно было бы выбрать. Это действительно пример шести / полдюжины. Логика объединения значений абсолютно одинакова; один и тот же вход генерирует одинаковый выход из каждого (в отличие от моноидов Sum и Product для Int, потому что они генерируют разные результаты при объединении Ints).

Итак, резюмируем: моноид в категории эндофункторов описывает:

   ~t :: m * -> m * -> m *
   and a neutral value for m *

(<*>)и (>>=)оба обеспечивают одновременный доступ к двум mзначениям для вычисления единственного возвращаемого значения. Логика, используемая для вычисления возвращаемого значения, точно такая же. Если бы не различные формы функций, которые они параметризуют (по f :: a -> bсравнению с k :: a -> m b), и положение параметра с одним и тем же типом возврата вычислений (т. a -> b -> bЕ. По сравнению b -> a -> bс каждым соответственно), я подозреваю, что мы могли бы параметризовать моноидальную логику, тензорное произведение, для повторного использования в обоих определениях. В качестве упражнения, чтобы понять суть, попробуйте и осуществите ~t, и вы в конечном итоге (<*>)и в (>>=)зависимости от того, как вы решите его определить forall a b.

Если моя последняя точка концептуально верна как минимум, тогда она объясняет точное и единственное вычислительное различие между Applicative и Monad: функции, которые они параметризуют. Другими словами, разница является внешней по отношению к реализации этих классов типов.

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

Тем не менее, есть ирония в том, что я впервые неправильно понял применимость заявления за пределами монады, и то, что я надеюсь передать здесь. Все, что он описывает, оказывается похожим между Applicative и Monads (и Arrows среди других). Чего не говорится, так это небольшого, но полезного различия между ними.

- E

Ответы здесь отлично справляются с определением моноидов и монад, однако они все еще не отвечают на вопрос:

И на менее важной ноте, правда ли это, и если да, то могли бы вы дать объяснение (надеюсь, что оно может быть понято кем-то, кто не имеет большого опыта в Haskell)?

Суть вопроса, который здесь отсутствует, - это другое понятие «моноид», точнее , так называемая категоризация - понятие «моноид» в моноидальной категории. К сожалению, сама книга Мак Лэйна делает ее очень запутанной :

В общем, монада X- это просто моноид в категории эндофункторов X, продукт ×заменяется составом эндофункторов, а единица устанавливается единичным эндофунктором.

Главное замешательство

Почему это сбивает с толку? Потому что он не определяет, что такое «моноид в категории эндофункторов» X. Вместо этого в этом предложении предлагается взять моноид внутри множества всех эндофункторов вместе с композицией функторов в качестве двоичной операции и функтором тождеств в качестве моноидальной единицы. Который прекрасно работает и превращает в моноид любое подмножество эндофункторов, которое содержит тождественный функтор и закрыто под композицией функторов.

Тем не менее, это не правильное толкование, которое книга не может прояснить на этом этапе. Монада f- это фиксированный эндофунктор, а не подмножество эндофункторов, замкнутых в композиции. Обычной конструкцией является использование fдля создания моноида путем взятия множества kразложенных композиций.f^k = f(f(...)) из fс самими собой, в том числе , k=0что соответствует идентичности f^0 = id. И теперь набор Sвсех этих полномочий для всех k>=0действительно является моноидом «с произведением ×, замененным композицией эндофункторов и единицей, установленной единичным эндофунктором».

И все еще:

• Это моноид S может быть определен для любого функтора fили даже буквально для любой собственной карты X. Это моноид, созданный f.
• Моноидальная структура S заданная композицией функторов и функтором идентичности, не имеет ничего общего с тем, fбыть или не быть монадой.

И чтобы сделать вещи более запутанными, определение «моноид в моноидальной категории» приходит позже в книге, как вы можете видеть из оглавления . И все же понимание этого понятия абсолютно необходимо для понимания связи с монадами.

(Строгие) моноидальные категории

Переходя к главе VII на моноидах (который приходит позже , чем глава VI на монадах), мы находим определение так называемой строгой категории моноидальной как тройные (B, *, e), где Bкатегорию, *: B x B-> Bв бифунктора (функтор по отношению к каждому компоненту с другим компонентом фиксированного ) и eявляется единичным объектом B, удовлетворяющим законам ассоциативности и единицы:

(a * b) * c = a * (b * c)
a * e = e * a = a

для любых объектов a,b,cиз B, и того же тождества для любых морфизмов a,b,cс eзаменено id_e, тождественным морфизмом e. Теперь полезно отметить, что в нашем интересном случае, где Bесть категория эндофункторов Xс естественными преобразованиями в виде морфизмов, *композиция функторов и eфунктор тождества, все эти законы выполняются, что можно непосредственно проверить.

Далее в книге дается определение «расслабленной» моноидальной категории , где законы выполняются только по модулю некоторых фиксированных естественных преобразований, удовлетворяющих так называемым отношениям когерентности. , что, однако, не важно для наших случаев категорий эндофункторов.

Моноиды в моноидальных категориях

Наконец, в разделе 3 «Моноиды» главы VII дано фактическое определение:

Моноид cв моноидальной категории (B, *, e)- объект Bс двумя стрелками (морфизмы)

mu: c * c -> c
nu: e -> c

сделать 3 диаграммы коммутативными. Напомним, что в нашем случае это морфизмы в категории эндофункторов, которые являются естественными преобразованиями, соответствующими точно joinи returnдля монады. Связь становится еще более ясной, когда мы делаем композицию *более явной, заменяя ее c * cтем c^2, где cнаходится наша монада.

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

Вывод

Таким образом, любая монада по определению является эндофунктором, следовательно, объектом в категории эндофункторов, где монады joinи returnоператоры удовлетворяют определению моноида в этой конкретной (строгой) моноидальной категории . Наоборот, любой моноид в моноидальной категории эндофункторов по определению является тройкой, (c, mu, nu)состоящей из объекта и двух стрелок, например, в нашем случае естественных преобразований, удовлетворяющих тем же законам, что и монада.

Наконец, обратите внимание на ключевое различие между (классическими) моноидами и более общими моноидами в моноидальных категориях. Две стрелки muи nuвыше больше не являются бинарной операцией и единым целым в наборе. Вместо этого у вас есть один фиксированный endofunctor c. Композиция функтора *и один только функтор идентичности не обеспечивают полной структуры, необходимой для монады, несмотря на это запутанное замечание в книге.

Другой подход был бы сравнить со стандартным моноиде Cвсех самостоятельных отображений множества A, где бинарная операция является композиция, которая может быть замечена , чтобы отобразить стандартный декартово произведение C x Cв C. Переходя к категоризированному моноиду, мы заменяем декартово произведение xна функторную композицию *, и бинарная операция заменяется естественным преобразованием muиз c * cв c, то есть набором joinоператоров.

join: c(c(T))->c(T)

для каждого объекта T(введите в программировании). И элементы идентичности в классических моноидах, которые могут быть идентифицированы с изображениями карт из фиксированного одноточечного множества, заменяются набором returnоператоров

return: T->c(T) 

Но теперь нет больше декартовых произведений, поэтому нет пар элементов и, следовательно, нет бинарных операций.