Я не говорил, что она не является частью. «теорию групп и прочую абстрактную алгебру» – значит одна часть и все остальные части целого. А насчёт нужно забывать или нет – к чему говорить о долге, я говорю о том, что многие действительно забывают. Или Вы рассчитываете, что все помнят, постоянно используют и понимают это?
Так-то оно так. Но я рассчитываю всё же на не подготовленного читателя: думаю, на хабре в основном программисты, которые хотя и учились в техническом вузе, давно забыли теорию групп и прочую абстрактную алгебру.
.
В любом случае я не вижу проблем с теми, кто знает теорию групп — я ведь никого не обманываю эквивалентными определениями — напротив, таким подкованным читателям по-моему полезно взглянуть на знакомое понятие с нового ракурса.
Нет, если в данном примере убрать стрелку g, то всё будет в порядке, будет категория с двумя стрелками из B в A. Количество морфизмов не ограничивается таким образом. Просто нужно чтобы они не «конфликтовали» между собой.
Не выполняется ассоциативность:
должно быть: f ∘ (g ∘ h) ≡ (f ∘ g) ∘ h
Распишем левую часть:
В скобках: g ∘ h ≡ id ∷ B → B
следовательно: f ∘ (g ∘ h) ≡ f ∘ id ≡ f
Теперь правая часть:
В скобках: f ∘ g ≡ id ∷ A → A
следовательно: (f ∘ g) ∘ h ≡ id ∘ h ≡ h
Получилось, что левая часть – это f, а правая – h, но f ≠ h, т.к. это разные морфизмы (разные стрелки).
Думаю стоит пояснить, почему в скобках получался id. По определению композиции, для любых двух морфизмов с совпадающей областью/кообластью (читай стрелок с общим концом/началом) существует морфизм, называемый их композицией, то есть такая стрелка, что она действует из области первой в кообласть второй: h ∷ B → A g ∷ A → B g ∘ h ∷ B → B
А единственная стрелка из B в B – это id ∷ B → B, значит она и является этой композицией. Аналогично с композицией f ∘ g.
Это действительно одно и то же. Вот что пишет Маклейн:
«Моноид – это категория с одним объектом. Как следствие, моноид определяется множеством своих стрелок, единичной стрелкой и правилом композиции стрелок. Поскольку произведение определено для любой пары стрелок, то моноид можно описать как множество M с бинарной операцией M x M --> M, ассоциативной и имеющей единицу. Таким образом, моноид – то же самое, что полугруппа с единицей.»
(«Категории для работающего математика», Гл 1.2)
Разница просто в используемой терминологии. С точки зрения изложения материала, я посчитал, что правильнее привести сначала пример того, что читатель уже знает – категории, но именно категории с одним объектом и потом объяснить, что уже известные категорные аксиомы, в данном частном случае, называются структурой моноида. А потом можно объяснять другие ипостаси этого понятия и приводить примеры множеств с бинарной операцией. Я предполагаю, что читатель может ничего не знать о теории групп и потому не лезу в отдельную теорию, которая не является необходимой для основной темы статьи ")
Хм,, даже не думал, что у кого-то возникнут проблемы с юникодовскими символами… У меня в браузере по умолчанию шрифты Times и Courier. Пока писал, в редакторе использовал Monofur.
А какой именно символ у Вас отображается квадратиком? Просто Вы скопировали из поста видимо и оно у меня в тут и там нормально всё выглядит. Там написано: a -> Maybe a -> [Maybe a]. Только вместо «a» – альфа, а вместо "->" – другая стрелочка, что-то типа |-->.
Это признаю ") Но я намеренно не касался этой темы, чтобы не пришлось говорить о каррировании – это ведь надо отдельно подробно объяснять, но это не входит в основную тему статьи. Я вроде бы аккуратно обошёл эту тему – примеры функторов с одним параметром. Я рассуждал так, что у того, кто не знает про каррирование скорее всего не возникнет такого вопроса, а тот, кто знает, поймёт сам то, что я написал в комментарии выше – Вы же это понимали ")
instance Functor (Either a) – это да. Только это инстанс для типа (Either a) :: ∗ → ∗, а не для типа Either. Когда Вы дали конструктору типа Either один параметр – это уже другой тип, однопараметрический. Так же как и обычные функции, конструкторы в Haskell каррированные, то можно всегда считать, что они имеют один параметр: Either :: ∗ → (∗ → ∗)
Вот писал и, Вас поминая, три раза исправлял:
«кайнд» (как было в комментарии jtootf) → «сорт» (как Вы рекомендуете) → «kind» (чтобы не заморачиваться) → ну и наконец «вид» – я подумал, Вы не заметите… (;
Простите, но я Вас не очень понял. Если говорить конкретно о классе Functor, то все его воплощения должны иметь вид ∗ → ∗. У вас не получится написать instance Functor Either where ...
– каков должен тогда быть тип у fmap?
Поясните, пожалуйста, что Вы имели ввиду.
О, кстати опять же в Мягком введении в Haskell увидел, что тоже пишут «вид»…
Всё же, имхо, с учётом сказанного в комментариях 1 и 2, «тип терма, вид типа, сорт вида» – самый хороший вариант.
Спасибо. А скажите, текст стал сложнее по содержанию или по изложению? Я так понимаю, что говоря о многочисленных новых обозначениях и определениях, Вы имеете ввиду второе, но достаточно ли просто объясняется то, что кроется за вводимыми обозначениями?
Я смотрю на всё это следующим образом:
С одной стороны введение терминологии и обозначений далеко не всегда является необходимым, но с другой стороны, оно нацеленно на то, чтобы упростить дальнейшее изложение, сделать его язык более высокоуровневым. Другое дело, что для того, что для того, чтобы читатель мог легко понимать этот новый язык, он должен приобрести интуитивное восприятие вводимых терминов, чтобы читая их не расшифровывать каждый раз, а понимать в целом. И задача автора в том, чтобы упростить формирование этой интуиции у читателя — с помощью наглядных примеров, аналогий и экстраполяций.
Вероятно, мои тексты далеко не соответствуют описанной методологии, но я к этому стремлюсь, поэтому я буду рад любой конструктивной, конкретной критике и постараюсь учесть ошибки в дальнейшем.
Насчёт перевода «instance» как «воплощение» — я встречал такой вариант в Мягком введении в Haskell. И мне кажется, это слово достаточно хорошо отражает смысл понятия класс как абстракции, которую воплощают в себе конкретные сущности. «Экземпляр» же с одной стороны отражает суть класса как совокупности типов, что тоже хорошо. Думаю, стоит чередовать эти термины, поскольку они не противоречат друг другу ")
.
В любом случае я не вижу проблем с теми, кто знает теорию групп — я ведь никого не обманываю эквивалентными определениями — напротив, таким подкованным читателям по-моему полезно взглянуть на знакомое понятие с нового ракурса.
g, то всё будет в порядке, будет категория с двумя стрелками изBвA. Количество морфизмов не ограничивается таким образом. Просто нужно чтобы они не «конфликтовали» между собой.должно быть:
f ∘ (g ∘ h) ≡ (f ∘ g) ∘ hРаспишем левую часть:
В скобках:
g ∘ h ≡ id ∷ B → Bследовательно:
f ∘ (g ∘ h) ≡ f ∘ id ≡ fТеперь правая часть:
В скобках:
f ∘ g ≡ id ∷ A → Aследовательно:
(f ∘ g) ∘ h ≡ id ∘ h ≡ hПолучилось, что левая часть – это
f, а правая –h, ноf ≠ h, т.к. это разные морфизмы (разные стрелки).Думаю стоит пояснить, почему в скобках получался
id. По определению композиции, для любых двух морфизмов с совпадающей областью/кообластью (читай стрелок с общим концом/началом) существует морфизм, называемый их композицией, то есть такая стрелка, что она действует из области первой в кообласть второй:h ∷ B → Ag ∷ A → Bg ∘ h ∷ B → BА единственная стрелка из
BвB– этоid ∷ B → B, значит она и является этой композицией. Аналогично с композициейf ∘ g.Если что-то не пояснил – спрашивайте (;
(«Категории для работающего математика», Гл 1.2)
Разница просто в используемой терминологии. С точки зрения изложения материала, я посчитал, что правильнее привести сначала пример того, что читатель уже знает – категории, но именно категории с одним объектом и потом объяснить, что уже известные категорные аксиомы, в данном частном случае, называются структурой моноида. А потом можно объяснять другие ипостаси этого понятия и приводить примеры множеств с бинарной операцией. Я предполагаю, что читатель может ничего не знать о теории групп и потому не лезу в отдельную теорию, которая не является необходимой для основной темы статьи ")
А какой именно символ у Вас отображается квадратиком? Просто Вы скопировали из поста видимо и оно у меня в тут и там нормально всё выглядит. Там написано: a -> Maybe a -> [Maybe a]. Только вместо «a» – альфа, а вместо "->" – другая стрелочка, что-то типа |-->.
instance Functor (Either a)– это да. Только это инстанс для типа(Either a) :: ∗ → ∗, а не для типаEither. Когда Вы дали конструктору типа Either один параметр – это уже другой тип, однопараметрический. Так же как и обычные функции, конструкторы в Haskell каррированные, то можно всегда считать, что они имеют один параметр:Either :: ∗ → (∗ → ∗)«кайнд» (как было в комментарии jtootf) → «сорт» (как Вы рекомендуете) → «kind» (чтобы не заморачиваться) → ну и наконец «вид» – я подумал, Вы не заметите… (;
«экземпляр воплощает класс в типе» – это хорошо, ёмко.
∗ → ∗. У вас не получится написатьinstance Functor Either where ...– каков должен тогда быть тип у
fmap?Поясните, пожалуйста, что Вы имели ввиду.
Всё же, имхо, с учётом сказанного в комментариях 1 и 2, «тип терма, вид типа, сорт вида» – самый хороший вариант.
Вы спрашивайте, если что непонятно – буду рад разъяснить (;
Я смотрю на всё это следующим образом:
С одной стороны введение терминологии и обозначений далеко не всегда является необходимым, но с другой стороны, оно нацеленно на то, чтобы упростить дальнейшее изложение, сделать его язык более высокоуровневым. Другое дело, что для того, что для того, чтобы читатель мог легко понимать этот новый язык, он должен приобрести интуитивное восприятие вводимых терминов, чтобы читая их не расшифровывать каждый раз, а понимать в целом. И задача автора в том, чтобы упростить формирование этой интуиции у читателя — с помощью наглядных примеров, аналогий и экстраполяций.
Вероятно, мои тексты далеко не соответствуют описанной методологии, но я к этому стремлюсь, поэтому я буду рад любой конструктивной, конкретной критике и постараюсь учесть ошибки в дальнейшем.
Насчёт перевода «instance» как «воплощение» — я встречал такой вариант в Мягком введении в Haskell. И мне кажется, это слово достаточно хорошо отражает смысл понятия класс как абстракции, которую воплощают в себе конкретные сущности. «Экземпляр» же с одной стороны отражает суть класса как совокупности типов, что тоже хорошо. Думаю, стоит чередовать эти термины, поскольку они не противоречат друг другу ")