Разве Монад не синтаксический сахар?

Я прошел через различные статьи/статьи/блоги, а что не о Монадах. Люди говорят о них в разных контекстах, таких как теория категорий (что в мире такое?) И т.д. Пройдя все это и пытаясь понять и написать монадический код, я пришел к пониманию, что монады - это просто синтаксический сахар (возможно, самый прославлял их всех). Будь то обозначение в Haskell или Вычисление Выражений в F # или даже LINQ, выберите много операторов (помните, что синтаксис LINQ также является синтаксическим сахаром в С#/VB).

Мой вопрос: если кто-то верит, что монады - это больше, чем синтаксический сахар (над вложенными вызовами метода), тогда, пожалуйста, просветите меня "практичность", а не "теоретические концепции".

Спасибо всем.

UPDATE:

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

Ответ 1

Монада не синтаксический сахар; У Haskell есть сахар для работы с монадами, но вы можете использовать их без сахара и операторов. Таким образом, Haskell на самом деле не поддерживает "монады" больше, чем загружает другие языки, просто упрощает их использование и внедрение. Монада не является конструкцией программирования или языковой функцией как таковой; это абстрактный способ мышления об определенных типах объектов, которые, когда они интуитивно понятны как типы Хаскелла, обеспечивают хороший способ мышления о передаче состояния по типам, который позволяет Haskell (или даже любой язык при мыслите о функциональности) делать свою вещь,

Ответ 2

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

Итак, чтобы ответить на ваш вопрос: Monad не является синтаксическим сахаром, это класс типа, однако обозначение do является синтаксическим сахаром (и, конечно, полностью необязательным - вы можете использовать монады просто отлично без обозначения do).

Ответ 3

По определению, монады не являются синтаксическим сахаром. Это тройка операций (return/unit, map и join) над юнитом значений (списки, наборы, типы опций, функции состояния, продолжения и т.д.), Которые подчиняются небольшому числу законов. Как используется в программировании, эти операции выражаются как функции. В некоторых случаях, таких как Haskell, эти функции могут быть выражены полиморфно над всеми монадами, используя классы типов. В других случаях эти функции должны иметь другое имя или пространство имен для каждой монады. В некоторых случаях, таких как Haskell, существует слой синтаксического сахара, чтобы сделать программирование с этими функциями более прозрачным.

Итак, Monads - это не вложенные вызовы функций per se, и, разумеется, они не касаются сахара. Они касаются самих трех функций, типов ценностей, которыми они управляют, и законов, которым подчиняются эти функции.

Ответ 4

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

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

Конечно, есть и другие способы получить эту функцию, но это всего лишь один, надеюсь, "практический" пример.

Ответ 5

Нет,

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

В этом случае шаблон значений добавляет информацию (или, если вам нравятся данные внутри каких-то мешков, но эта картина не сохраняется для каждой монады) и способ их сближения.

Синтаксический рекомендатор - это всего лишь небольшой удобный способ создания привязок;) Его расширение к веществу;)

Для практических понятий: просто посмотрите на async-workflow или IO monad - должно быть достаточно практично;)

Ответ 6

Я бы назвал его шаблоном в том смысле, что m a → (a → m b) → m b (с разумным поведением) удобен для многих разных конструкторов проблем/типов.

На самом деле так удобно, что он заслуживает предоставления синтаксического сахара на языке. То, что обозначение do в Haskell, from в С#, for понимается в scala. Синтаксический сахар требует только соблюдения шаблона именования при реализации (selectMany в С#, flatMap в scala). Эти языки делают это, если Monad не является типом в своих библиотеках (в scala, можно написать). Обратите внимание, что С# также делает это для итератора шаблона. Хотя есть интерфейс IEnumerable, foreach переводится на вызовы GetEnumerator/MoveNext/Current на основе имени методов, независимо от типов. Только когда перевод сделан, он проверяет, что все определено и хорошо напечатано.

Но в Haskell (это может быть сделано в Scala или OCaml тоже, не в С#, и я считаю, что это невозможно в F #), Monad - это больше, чем шаблон дизайна + синтаксический сахар, основанный на шаблоне именования. Это фактический API, программный компонент, что угодно.

Рассмотрим шаблон итератора в (статически типизированных) императивных языках. Вы можете просто реализовать MoveNext/Current (или hasNext/next) в классах, где это подходит. И если для этого есть какой-то синтаксический сахар, такой как С#, это уже очень полезно. Но если вы сделаете его интерфейсом, вы можете сразу сделать гораздо больше. У вас могут быть вычисления, которые работают на любом итераторе. У вас есть методы утилиты на итераторе (find, filter, chain, nest..), что делает их более мощными.

Когда Monad - это тип, а не просто шаблон, вы можете сделать то же самое. У вас могут быть функции утилит, которые делают работу с Monad более мощной (в Control.Monad) вы можете иметь вычисления, в которых тип монады для использования является параметр (см. эту старую статью от Wadler, показывающую, как интерпретатор может быть параметризован типом монады и что делают различные экземпляры). Чтобы иметь тип монады (тип класса), вам нужен какой-то тип более высокого порядка, то есть вам нужно иметь возможность параметризовать конструктор типа, а не простой тип данных.