Понимание, почему Молния является Comonad

Question

Понимание, почему Молния является Comonad

112

Это ответ на ответ на мой предыдущий вопрос.

Предположим, мне нужно сопоставить каждый элемент a:A от List[A] до b:B с помощью функции def f(a:A, leftNeighbors:List[A]): B и сгенерировать List[B].

Очевидно, я не могу просто вызвать map в списке, но я могу использовать список zipper. Застежка-молния - это курсор для перемещения по списку. Он обеспечивает доступ к текущему элементу (focus) и его соседям.

Теперь я могу заменить my f на def f'(z:Zipper[A]):B = f(z.focus, z.left) и передать эту новую функцию f' в cobind метод Zipper[A].

cobind работает следующим образом: он вызывает f' с помощью молнии, затем перемещает застежку-молнию, вызывает f' с новой "перемещенной" молнией, снова перемещает застежку-молнию и т.д. и т.д... пока молния не дойдет до конца списка.

Наконец, cobind возвращает новую застежку-молнию типа Zipper[B], которая может быть преобразована в список, и поэтому проблема решена.

Теперь обратите внимание на симметрию между cobind[A](f:Zipper[A] => B):Zipper[B] и bind[A](f:A => List[B]):List[B]. Поэтому List является Monad и Zipper является Comonad.

Имеет ли смысл?

Michael 03 июнь 2014, в 11:47

Источник

1

Я не эксперт, но это имеет для меня смысл. У меня было прозрение во время чтения вашего объяснения. Спасибо!
acjay 03 июнь 2014, в 18:11
7

На ваш вопрос очень сложно ответить в формате SO ... но вы абсолютно правы. Застежки-молнии, ориентированные на элемент, всегда являются комонадами.
J. Abrahamson 28 авг. 2014, в 16:55
1

Этот ответ также может помочь: stackoverflow.com/questions/25554062/…
J. Abrahamson 11 апр. 2015, в 04:15
0

Спасибо. Я не знаю Haskell но я проверю это.
Michael 11 апр. 2015, в 04:26
4

Список можно также рассматривать как комонаду (несколькими способами), тогда как Застежка-молния может быть разыграна как монада (также во многих отношениях). Разница в том, сосредоточены ли вы на «конструктивном» добавлении данных к конечному автомату (об этом интерфейс Monad) или на «извлечении» состояния из него «деконструктивно» (это то, что делает Comonad). Однако нелегко ответить на вопрос, сформулированный как «имеет ли это понимание смысл». В каком-то смысле это так, в другом - нет.
KT. 03 янв. 2016, в 13:05
0

@KT. Спасибо за комментарий. Можете ли вы привести простой пример использования List в качестве Comonad ?
Michael 03 янв. 2016, в 17:43
2

Чтобы преобразовать что-либо в comonad, вам нужно предоставить две операции: 1) извлечение значения (например, оно может быть заголовком списка) и 2) применение операции обработки списка (например, вы можете применить это в скользящем оконным способом вдоль списка или поэлементным способом или тому подобным, предполагая, что соответствующее единичное преобразование не изменит список). Имеет ли смысл такой способ обработки списка, это отдельный вопрос. Обратите внимание, что пустой интерфейс comonad не предоставляет ни способа создания списка, ни его обхода. Он знает только, как использовать операции со списком.
KT. 03 янв. 2016, в 18:08
0

@KT. Еще раз спасибо. Знаете ли вы какое-либо простое применение такого списка Comonad? Я думаю об unescaping строки (списка символов), где вам нужна функция List[Char] => Char .
Michael 03 янв. 2016, в 18:10
0

@ Майкл, действительно, я полагаю, вы могли бы рассматривать неэкранирующую операцию (или, в более общем смысле, токенизатор / анализатор / преобразователь сигналов) как основанную на списке (или, более часто, потоковую) комонаду. Тот факт, что вы можете это сделать, не означает, что это пример правильного «приложения». Необходимость введения такой абстракции должна исходить из другого места, и я недостаточно функционально ориентирован, чтобы это увидеть. «Добавление математики ради математики», на мой взгляд, не является разумной необходимостью.
KT. 03 янв. 2016, в 18:37
0

@KT. Да, я согласен. «Эскейпинг» не тот случай, для которого нужна comonad . Однако было бы интересно найти реальное «правильное» приложение для этой comonad ...
Michael 03 янв. 2016, в 18:43
0

@Michael, проверьте это: jucs.org/jucs_11_7/signals_and_comonads/… В этой статье основное внимание уделяется потокам, потому что математически поток, являющийся типом corecursive, является чистой моделью для всего бесконечного и "co-", в то время как список, будучи рекурсивным типом, имеет окончание, которое необходимо обрабатывать как особый случай. Но кроме этой проблемы конечности, где бы вы ни увидели комонаду над потоком, вы также должны быть в состоянии преобразовать ее в комонаду по списку. ... Мне нужно бежать, армия теоретиков собирается говорить грязные ереси.
KT. 03 янв. 2016, в 18:55
0

@KT. Большое спасибо за ссылку.
Michael 03 янв. 2016, в 20:23
0

Также я нашел много полезных идей в этих сообщениях в блоге.
pagoda_5b 09 апр. 2016, в 01:44
0

@ Майкл Это было для меня без ответа. Будет ли уместно написать относительно простой вопрос, а затем дать в качестве ответа большую часть исходного вопроса? (Т.е. переформулируйте свой вопрос, а затем ответьте на него самостоятельно.) Если вы не хотите, чтобы баллы отвечали на него самостоятельно, вы можете пометить его как вики сообщества.
eenblam 18 фев. 2017, в 16:36
0

@ J.Abrahamson Это поможет вам решить проблему с форматом SO и исключить его из списка без ответа.
eenblam 18 фев. 2017, в 16:38
2

@eenblam Вы правы. Я добавлю ответ, и я надеюсь, что этот вопрос будет удален из списка без ответа.
Michael 18 фев. 2017, в 19:33

Показать ещё 14 комментариев

Теги:

scala

functional-programming

zipper

comonad

1 ответ

Ещё вопросы

Я не эксперт, но это имеет для меня смысл. У меня было прозрение во время чтения вашего объяснения. Спасибо!
На ваш вопрос очень сложно ответить в формате SO ... но вы абсолютно правы. Застежки-молнии, ориентированные на элемент, всегда являются комонадами.
Этот ответ также может помочь: stackoverflow.com/questions/25554062/…
Спасибо. Я не знаю Haskell но я проверю это.
Список можно также рассматривать как комонаду (несколькими способами), тогда как Застежка-молния может быть разыграна как монада (также во многих отношениях). Разница в том, сосредоточены ли вы на «конструктивном» добавлении данных к конечному автомату (об этом интерфейс Monad) или на «извлечении» состояния из него «деконструктивно» (это то, что делает Comonad). Однако нелегко ответить на вопрос, сформулированный как «имеет ли это понимание смысл». В каком-то смысле это так, в другом - нет.
@KT. Спасибо за комментарий. Можете ли вы привести простой пример использования List в качестве Comonad ?
Чтобы преобразовать что-либо в comonad, вам нужно предоставить две операции: 1) извлечение значения (например, оно может быть заголовком списка) и 2) применение операции обработки списка (например, вы можете применить это в скользящем оконным способом вдоль списка или поэлементным способом или тому подобным, предполагая, что соответствующее единичное преобразование не изменит список). Имеет ли смысл такой способ обработки списка, это отдельный вопрос. Обратите внимание, что пустой интерфейс comonad не предоставляет ни способа создания списка, ни его обхода. Он знает только, как использовать операции со списком.
@KT. Еще раз спасибо. Знаете ли вы какое-либо простое применение такого списка Comonad? Я думаю об unescaping строки (списка символов), где вам нужна функция List[Char] => Char .
@ Майкл, действительно, я полагаю, вы могли бы рассматривать неэкранирующую операцию (или, в более общем смысле, токенизатор / анализатор / преобразователь сигналов) как основанную на списке (или, более часто, потоковую) комонаду. Тот факт, что вы можете это сделать, не означает, что это пример правильного «приложения». Необходимость введения такой абстракции должна исходить из другого места, и я недостаточно функционально ориентирован, чтобы это увидеть. «Добавление математики ради математики», на мой взгляд, не является разумной необходимостью.
@KT. Да, я согласен. «Эскейпинг» не тот случай, для которого нужна comonad . Однако было бы интересно найти реальное «правильное» приложение для этой comonad ...
@Michael, проверьте это: jucs.org/jucs_11_7/signals_and_comonads/… В этой статье основное внимание уделяется потокам, потому что математически поток, являющийся типом corecursive, является чистой моделью для всего бесконечного и "co-", в то время как список, будучи рекурсивным типом, имеет окончание, которое необходимо обрабатывать как особый случай. Но кроме этой проблемы конечности, где бы вы ни увидели комонаду над потоком, вы также должны быть в состоянии преобразовать ее в комонаду по списку. ... Мне нужно бежать, армия теоретиков собирается говорить грязные ереси.
Также я нашел много полезных идей в этих сообщениях в блоге.
@ Майкл Это было для меня без ответа. Будет ли уместно написать относительно простой вопрос, а затем дать в качестве ответа большую часть исходного вопроса? (Т.е. переформулируйте свой вопрос, а затем ответьте на него самостоятельно.) Если вы не хотите, чтобы баллы отвечали на него самостоятельно, вы можете пометить его как вики сообщества.
@ J.Abrahamson Это поможет вам решить проблему с форматом SO и исключить его из списка без ответа.
@eenblam Вы правы. Я добавлю ответ, и я надеюсь, что этот вопрос будет удален из списка без ответа.

KT. · Accepted Answer · 2017-04-14T14-53-00.000Z

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

A List также можно рассматривать как комонад (по-разному), а Zipper можно отличить как монаду (также по-разному). Разница заключается в том, концептуально ли вы концептуально сосредоточены на "добавлении" данных на конечный автомат (что означает интерфейс Monad) или "извлечение" из него "деконструктивно" (что делает Comonad),.

Нелегко ответить на вопрос, заявляя, что "понимает ли это понимание смысл". В некотором смысле это происходит, а в другом - нет.