Comments 46
Спасибо за статью!
И как всегда объяснения на Хаскеле:) Думаю, для людей знакомых с Хаскелем, думаю это все и так понятно, а для незнакомых… сложно просто ориентироваться в коде, в синтаксисе языка, даже чтобы «распарсить» программу в уме.
Я время от времени все пытаюсь понять, что же такое эти функторы и монады, чего-то даже иногда понимаю, но единой картины все-же нет.
Начать надо с вопроса — что такое алгебраический тип данных и в чем его отличие от неалгебраических? Если пользоваться терминологией императивных языков, то например переменная типа int — АТД? Массив чисел? Структура? Класс?
В вашей предыдущей статье вы даете определение АТД как «АТД называются алгебраическими, потому что их можно представить как некую алгебраическую композицию типов его составляющих», но это все-же несколько не то, что могло бы облегчить понимание)…
И как всегда объяснения на Хаскеле:) Думаю, для людей знакомых с Хаскелем, думаю это все и так понятно, а для незнакомых… сложно просто ориентироваться в коде, в синтаксисе языка, даже чтобы «распарсить» программу в уме.
Я время от времени все пытаюсь понять, что же такое эти функторы и монады, чего-то даже иногда понимаю, но единой картины все-же нет.
Начать надо с вопроса — что такое алгебраический тип данных и в чем его отличие от неалгебраических? Если пользоваться терминологией императивных языков, то например переменная типа int — АТД? Массив чисел? Структура? Класс?
В вашей предыдущей статье вы даете определение АТД как «АТД называются алгебраическими, потому что их можно представить как некую алгебраическую композицию типов его составляющих», но это все-же несколько не то, что могло бы облегчить понимание)…
Попробуйте прочитать вариацию на тему с С# habrahabr.ru/post/151703/
Я очень хочу разобраться в этом вопросе и помочь разобраться другим. Статью ту я с интересом читал как и многие другие статьи по теме здесь (но все равно спасибо, освежу в памяти).
Просто если есть люди, которые безусловно понимают тему на глубоком уровне (как автор топика), то почему не воспользоваться их присутствием на Хабре? Серией наводящих вопросов (возможно даже глупых) можно уточнить некоторые моменты, попытаться совместными усилиями переформулировать результаты обсуждения несколько раз до тех пор, пока не будет достигнуто полное понимание со стороны незнающих и согласие в корректности и полноте формулировок со стороны знающих.
Комментарии к статье ИМХО идеальный вариант для этой цели.
Просто если есть люди, которые безусловно понимают тему на глубоком уровне (как автор топика), то почему не воспользоваться их присутствием на Хабре? Серией наводящих вопросов (возможно даже глупых) можно уточнить некоторые моменты, попытаться совместными усилиями переформулировать результаты обсуждения несколько раз до тех пор, пока не будет достигнуто полное понимание со стороны незнающих и согласие в корректности и полноте формулировок со стороны знающих.
Комментарии к статье ИМХО идеальный вариант для этой цели.
Можно представить, что
Да,
Другое дело, что под капотом они реализованы по другому.
Списки — тоже АТД — рекурсивные
Структура — это обычный тупл(кортеж)
Тупл — это АТД
Класс — это структура со спец-способностями (инкапсуляция, полиморфизм, наследование)
Классов и объектов в Хаскеле нет.
Int определён так:data Int = -33554432 | -33554431 | ... |-2 | -1 | 0 | 1 | 2 | 3 | ... | 33554431 | 33554432
Да,
Int — АТД, как и любые типы в Хаскеле.Другое дело, что под капотом они реализованы по другому.
Списки — тоже АТД — рекурсивные
data List a = Nil | Cons a (List a)
Структура — это обычный тупл(кортеж)
Тупл — это АТД
data Struct = Struct Int (String->Int) String
Класс — это структура со спец-способностями (инкапсуляция, полиморфизм, наследование)
Классов и объектов в Хаскеле нет.
Какие типы не АТД? Что нужно «сломать» в АТД, чтобы он перестал быть АТД?
например, тип Collection n a — «коллекция из n элементов типа a», кажется, не может быть АДТ. Т. е. — это тип от терма.
да поправят меня математики, если это не так.
да поправят меня математики, если это не так.
Поясните плиз. Для меня «коллекция n элементив типа a» это массив a[n] :)
да, вы почти правильно написали на си:
a collection[n]; // так лучше
n — тут это число. Не тип. Т. е. — это терм. Т. е. — это значение некого типа, а не сам тип.
a collection[n]; // так лучше
n — тут это число. Не тип. Т. е. — это терм. Т. е. — это значение некого типа, а не сам тип.
То есть получается, что для списка Maybe будет работать, а для массива фиксированной длины — нет? Почему?
Потому что вам придется число(терм) выразить с помощью типа. Но в конечном итоге это уже не будет честный Algebraic Data Type (это будет называться Generalized Algebraic Data Type)
Определим стандартный (нефиксированный длины) список с указанием типа его конструкторов:
data List a where
Nil :: List a
Cons :: a -> List a -> List a
видите, оба конструктора имеют тип результата List a
теперь определим список с фиксированным количеством элементов.
сначала термы поднимем в типы. Вот аналог нуля и единицы:
data Zero
data Succ n
Вот как будут выглядеть алиасы для остальных натуральных чисел:
type One = Succ Zero
type Two = Succ One
type Three = Succ Two
type Four = Succ Three
Теперь определим сам список ListN:
data ListN n a where
Nil :: ListN Zero a
Cons :: a -> ListN n a -> ListN (Succ n) a
После этого тип списка из четырех картинок будет выглядеть так ListN Four Image
Как видите, в отличии от List a, типы результата двух конструкторов отличаются — один ListN Zero a, а второй ListN (Succ n) a.
Поэтому это не совсем ADT. Хотя в хаскелле его можно определить.
Определим стандартный (нефиксированный длины) список с указанием типа его конструкторов:
data List a where
Nil :: List a
Cons :: a -> List a -> List a
видите, оба конструктора имеют тип результата List a
теперь определим список с фиксированным количеством элементов.
сначала термы поднимем в типы. Вот аналог нуля и единицы:
data Zero
data Succ n
Вот как будут выглядеть алиасы для остальных натуральных чисел:
type One = Succ Zero
type Two = Succ One
type Three = Succ Two
type Four = Succ Three
Теперь определим сам список ListN:
data ListN n a where
Nil :: ListN Zero a
Cons :: a -> ListN n a -> ListN (Succ n) a
После этого тип списка из четырех картинок будет выглядеть так ListN Four Image
Как видите, в отличии от List a, типы результата двух конструкторов отличаются — один ListN Zero a, а второй ListN (Succ n) a.
Поэтому это не совсем ADT. Хотя в хаскелле его можно определить.
Ну я совсем не это хотел получить в ответ:) Меня интересует не реализация на хаскеле, а общие принципы.
Все что я хотел узнать — что такое АДТ с точки зрения классических императивных языков, а не Хаскеля.
Все что я хотел узнать — что такое АДТ с точки зрения классических императивных языков, а не Хаскеля.
АДТ, с императивной точки зрения, это продвинутый enum
Color = enum {Red, Green, Yellow, RGB(Byte, Byte, Byte) }
Эти enum еще могут иметь параметры (дженерики)
Так понятнее? :)
Color = enum {Red, Green, Yellow, RGB(Byte, Byte, Byte) }
Эти enum еще могут иметь параметры (дженерики)
Так понятнее? :)
Это я знаю, когда-то на rsdn читал статьи про язык nemerle. Это все определения той или иной степени формальности: от совсем неформальных («продвинутый enum») до строгих математических.
Но что это дает в реальном кодинге?
В чем киллер-фича ADT?
Но что это дает в реальном кодинге?
В чем киллер-фича ADT?
В мире со строгой типизацией кратко, лаконично и как можно точнее описать тип того, с чем ты работаешь.
Вот, например, описан тип выражающий грамматику javascript hackage.haskell.org/package/hjs-0.2.1/docs/HJS-Parser-JavaScript.html (тип JSProgram вконце странички).
Вот, например, описан тип выражающий грамматику javascript hackage.haskell.org/package/hjs-0.2.1/docs/HJS-Parser-JavaScript.html (тип JSProgram вконце странички).
Киллер-фича ADT, на мой взгляд — это простота в сочетании с гибкостью.
Классы смешивают воедино идентичность, состояние и поведение. Это сложно (не тяжело для восприятия, а просто объективно сложно: много сущностей, с которыми нельзя работать по отдельности)
Структуры недостаточно мощны: тип классических структур не может быть параметризован, и структуры представляют из себя произведение типов, но никогда — сумму (то есть если взять значение типа A И значение типа B, то можно получить значение структуры, содержащей A и B, но нельзя создать структуру, которая бы хранила значение типа A ИЛИ значение типа B)
ADT же просты, так как являются просто данными, без всяких смешений с какими-то идентичностями да поведениями, и при этом достаточно гибки, так как позволяют создавать сумму/произведение (алгебраическую композицию) других типов, да ещё и с параметрическим полиморфизмом (как в дженериках .net или java).
Благодаря этим двум свойствам ADT позволяют выразить очень много полезных типов данных и при этом достаточно удобно с ними работать посредством сопоставления с шаблоном, без написания горы методов для доступа к ним.
Например, в статье выше, определив в одну строку простейший тип данных Maybe, мы получили:
1) Параметризованный «контейнер» для 0 либо 1 элемента
2) Два конструктора: Just :: a -> Maybe a и Nothing :: Maybe a
3) Два «деконструктора» с аналогичными именами, которые используются при сопоставлении по шаблону и позволяют избежать условных операторов/операторов ветвлений, а также сравнений.
И всё это совершенно без дополнительных трудозатрат со стороны разработчика, то есть задаром.
К тому же можно было заметить строку deriving (Show), которая автоматически определила экземпляр класса типа Show для Maybe. Компилятор легко может создать этот и некоторые другие (например, Read, Eq, Ord) экземпляры автоматически, потому что ADT очень просты по своей сути.
Получается, что ADT — это удобный фреймворк для создания новых типов данных на основе композиции существующих.
Классы смешивают воедино идентичность, состояние и поведение. Это сложно (не тяжело для восприятия, а просто объективно сложно: много сущностей, с которыми нельзя работать по отдельности)
Структуры недостаточно мощны: тип классических структур не может быть параметризован, и структуры представляют из себя произведение типов, но никогда — сумму (то есть если взять значение типа A И значение типа B, то можно получить значение структуры, содержащей A и B, но нельзя создать структуру, которая бы хранила значение типа A ИЛИ значение типа B)
ADT же просты, так как являются просто данными, без всяких смешений с какими-то идентичностями да поведениями, и при этом достаточно гибки, так как позволяют создавать сумму/произведение (алгебраическую композицию) других типов, да ещё и с параметрическим полиморфизмом (как в дженериках .net или java).
Благодаря этим двум свойствам ADT позволяют выразить очень много полезных типов данных и при этом достаточно удобно с ними работать посредством сопоставления с шаблоном, без написания горы методов для доступа к ним.
Например, в статье выше, определив в одну строку простейший тип данных Maybe, мы получили:
1) Параметризованный «контейнер» для 0 либо 1 элемента
2) Два конструктора: Just :: a -> Maybe a и Nothing :: Maybe a
3) Два «деконструктора» с аналогичными именами, которые используются при сопоставлении по шаблону и позволяют избежать условных операторов/операторов ветвлений, а также сравнений.
И всё это совершенно без дополнительных трудозатрат со стороны разработчика, то есть задаром.
К тому же можно было заметить строку deriving (Show), которая автоматически определила экземпляр класса типа Show для Maybe. Компилятор легко может создать этот и некоторые другие (например, Read, Eq, Ord) экземпляры автоматически, потому что ADT очень просты по своей сути.
Получается, что ADT — это удобный фреймворк для создания новых типов данных на основе композиции существующих.
Не совсем. Вообще в языках с зависимыми типами(типа Coq, Agda) тоже есть АТД.
Объекты — не АТД, поскольку они обладают свойствами.
АТД — чистый тип, он не может обладать свойствами.
Объекты — не АТД, поскольку они обладают свойствами.
АТД — чистый тип, он не может обладать свойствами.
Кажется, вы немного неправы на счет Int. hackage.haskell.org/package/base-4.2.0.0/docs/Data-Int.html#t%3AInt
> A fixed-precision integer type with at least the range [-2^29… 2^29-1].
> A fixed-precision integer type with at least the range [-2^29… 2^29-1].
Полиморфизм в хаскелле есть в ассортименте.
Инкапсуляция есть: модули и GADT.
Далеко ходить не надо: IO a (без инкапсуляции любой дурак смог бы создать поддельный real world object и поломать порядок вычислений).
Наследование — с этим сложнее.
Интерфейс-реализация — это классы типов и их инстансы.
Инкапсуляция есть: модули и GADT.
Далеко ходить не надо: IO a (без инкапсуляции любой дурак смог бы создать поддельный real world object и поломать порядок вычислений).
Наследование — с этим сложнее.
Интерфейс-реализация — это классы типов и их инстансы.
> то например переменная типа int — АТД? Массив чисел? Структура? Класс?
Переменная типа Int — это АДТ. Вот псевдо-определение этого типа:
data Int = -536870912 | -536870911 |… | -1 | 0 | 1 |… | 536870910 | 536870911
Переменная типа Int — это АДТ. Вот псевдо-определение этого типа:
data Int = -536870912 | -536870911 |… | -1 | 0 | 1 |… | 536870910 | 536870911
Вот как обычно, статья с таким названием, будто я ее сейчас прочту и пойму зачем нужна вся эта функциональщина с хаскелями и прочими скалами
Но нет, после второго же абзаца все как всегда скатывается в дебри странных слов и непонятного кода
Или это я такой тупой?
Но нет, после второго же абзаца все как всегда скатывается в дебри странных слов и непонятного кода
Или это я такой тупой?
Пост просто назван неправильно. Было бы коррейтней его назвать «пример использования Maybe как функтора и как монады».
А Ваш вопрос можно разделить на два:
1) Зачем вообще нужны эти языки
2) Как понимать и использовать хаскель (скалу, что угодно ещё)
И если на первый вопрос ответить можно достаточно просто, то второй потребует практики и набивания руки.
А Ваш вопрос можно разделить на два:
1) Зачем вообще нужны эти языки
2) Как понимать и использовать хаскель (скалу, что угодно ещё)
И если на первый вопрос ответить можно достаточно просто, то второй потребует практики и набивания руки.
чесно, а что сложного в функциях?
Это функции сложения, добавление единицы, целочисленное деление.
bar = (+)
baz = (+ 1)
foo = div
Это функции сложения, добавление единицы, целочисленное деление.
Если смотреть на эти функции глазами математика, то в них нет ничего сложного. Вопросы возникают, когда на них смотрят глазами программиста. Какими типами данных оперируют эти функции? А что будет, если я сложу 32-битное знаковое с 16-битовым беззнаковым и какой тип будет иметь результат? А какова будет реакция на переполнение? Описана функция целочисленного деления, а для деления чисел с плавающей запятой используется одноимённая функция или другая? Есть функция «+ 1», а что – там нет обычного инкремента? Он даже в ассемблере есть.
Как-то многовато информации остаётся за кадром – для тех, кто не знает Хаскель. Чтобы понять функциональное программирование, нужно читать учебники. Но и в них многое остаётся за кадром. Есть люди, которым материал остаётся непонятным до тех пор, пока они не поймут, как это устроено изнутри. Си и Паскаль понятны, потому что известно, какой ассемблерный код они генерируют. А что генерирует Хаскель – увы, пока сие неведомо, хотя хотелось бы разобраться.
Как-то многовато информации остаётся за кадром – для тех, кто не знает Хаскель. Чтобы понять функциональное программирование, нужно читать учебники. Но и в них многое остаётся за кадром. Есть люди, которым материал остаётся непонятным до тех пор, пока они не поймут, как это устроено изнутри. Си и Паскаль понятны, потому что известно, какой ассемблерный код они генерируют. А что генерирует Хаскель – увы, пока сие неведомо, хотя хотелось бы разобраться.
Спасибо за ответ!
В Хаскеле с переполнением чисел не всё опрятно.
А вот сложить можно однотиповые числа:
то есть или только 32-битно-знаковые, или только 16-битовые беззнаковые.
Что касается целочисленного деления и нецелого деления, есть 2 функции:
Тут сложнее ответ. Ответ двояк — есть и нету одновременно.
Есть функция «следующее» для любых перечислимых типов данных:
А теперь что касается «обычного» инкремента, он подразумевает изменение переменной.
В Хаскеле все данные неизменяемые, поэтому функции инкремента, равно как и циклов (и много чего ещё) нет.
В Хаскеле с переполнением чисел не всё опрятно.
А вот сложить можно однотиповые числа:
(+) :: Num a => a -> a -> a
то есть или только 32-битно-знаковые, или только 16-битовые беззнаковые.
Что касается целочисленного деления и нецелого деления, есть 2 функции:
div :: Integral a => a -> a -> a
(/) :: Fractional a => a -> a -> a
Есть функция «+ 1», а что – там нет обычного инкремента?
Тут сложнее ответ. Ответ двояк — есть и нету одновременно.
Есть функция «следующее» для любых перечислимых типов данных:
succ :: Enum a => a -> a
А теперь что касается «обычного» инкремента, он подразумевает изменение переменной.
В Хаскеле все данные неизменяемые, поэтому функции инкремента, равно как и циклов (и много чего ещё) нет.
Вы хотите понять, как и где применять ФП, но при этом не имеете желания разбираться в нем. Не удивительно, что вы не понимаете.
Скалка раскрывает себя полноценно в многоядерных(процессорных), а так же кластерных системах. Akka вместе с иммутабельными структурами данных и функциональный подход в их обработке сокращают количество потенциальных ошибок до минимума (дедлоки например), при этом количество написанных строк гораздо меньше тех же реализаций каких-нибудь семафоров с тредами на джавасишках, да и система становится прозрачнее и понятнее, т.к. никакой черт из коробки дебрей кода внезапно не выскочит и не изменит нашу переменную просто потому, что ему так захотелось.
офк это все справедливо для более менее средних и крупных проектов. гостевые книги на этом писать имхо излишне…
офк это все справедливо для более менее средних и крупных проектов. гостевые книги на этом писать имхо излишне…
Наверное, дело в примерах. В этой статье из простой задачи делают сложную, пытаясь таким образом продемонстрировать мощь языка. Эффект получается противоположный, потому что делать надо наоборот: решать относительно сложную задачу так, чтобы решение получалось простым. Это по-настоящему интригует и мотивирует, особенно, если решение получается проще, чем на большинстве других популярных ЯП.
Не понятно зачем эта статья.
Те, кто не понимали\не знали азов монадного исчисления — не поймут. А те кто знали — зачем им еще одно, не самое очевидное, объяснение?
Нельзя использовать в качестве примера однобуквенные переменные, функции с именем foo, baz, <*> и >>=. Людей не знакомых с синтаксисом хаскеля и без этого много что смущать будет в примерах.
Ну а даже если и знаком с хаскелем — это все равно страшно:
Те, кто не понимали\не знали азов монадного исчисления — не поймут. А те кто знали — зачем им еще одно, не самое очевидное, объяснение?
Нельзя использовать в качестве примера однобуквенные переменные, функции с именем foo, baz, <*> и >>=. Людей не знакомых с синтаксисом хаскеля и без этого много что смущать будет в примерах.
Ну а даже если и знаком с хаскелем — это все равно страшно:
safebaz a b = baz <$> a <*> b... (>>=) :: m a -> (a -> m b) -> m b
Чтобы быстро получить представление о монадах и функторах, достаточно посмотреть вот этот очень толковый пост. Поясняется синтаксис конструкций и становится понятной общая идея. Все вполне понятно без знания синтакисиса.
Не совсем.
Вот допустим, я понял следующее.
Есть функция, принимающая на вход допустим тип T1 и возвращающая тип T2. Простая функция, ведать не ведающая ни о каких монадах.
Все эти конструкции (функторы, аппликативные функторы и монады) позволяют подавать на вход функции и получать на выходе этой функции разные другие типы, порожденные на основе T1 и T2 соответственно (например, Maybe, List, Future и т.д.). Что важно — без переписывания кода функции. Функция как не знала о монадах, так и дальше не знает, но мы получаем принципиально новые возможности в программе.
То есть если у нас есть функция увеличения числа на 1, мы можем ее совершенно прозрачно применить к целому списку чисел, получив на выходе другой список.
Я прав?
Вот допустим, я понял следующее.
Есть функция, принимающая на вход допустим тип T1 и возвращающая тип T2. Простая функция, ведать не ведающая ни о каких монадах.
Все эти конструкции (функторы, аппликативные функторы и монады) позволяют подавать на вход функции и получать на выходе этой функции разные другие типы, порожденные на основе T1 и T2 соответственно (например, Maybe, List, Future и т.д.). Что важно — без переписывания кода функции. Функция как не знала о монадах, так и дальше не знает, но мы получаем принципиально новые возможности в программе.
То есть если у нас есть функция увеличения числа на 1, мы можем ее совершенно прозрачно применить к целому списку чисел, получив на выходе другой список.
Я прав?
То есть если у нас есть функция увеличения числа на 1, мы можем ее совершенно прозрачно применить к целому списку чисел, получив на выходе другой список.
Я прав?
Да, все верно. Список в haskell — это тоже функтор и для списка определена композиция функции и значений списка.
UFO just landed and posted this here
Не покидает ощущение, что люди сначала создают себе проблемы (АДТ) а потом изобретают остроумные способы их решения (Монады и Функторы)
Ну да, лучше по старинке с null сравнивать.
Нет, ADT — это очень удобно. Это как правильно сделанный
union из C/C++. Вместе с (встроенным в язык) pattern matching — сильно упрощает код, и уменьшает количество мест, где можно ошибиться. К монадам и функторам отношения не имеет.
s/АДТ/отсутствие побочных эффектов/
ADT — это просто. Серьёзно. Не обязательно легко доступно для понимания, но очень просто по сути.
Есть примитивные типы, которые имеют только один экземпляр. Есть их суммы (объединение множеств значений) и произведения (декартово произведение множеств значений). Есть параметрический полиморфизм: Bool не паметризован ничем и живёт сам по себе, Maybe a параметризован типом элемента. Всё. Больше в ADT нет ничего. Это намного меньше, чем то, что есть в системах типов классических ООП-языков, и при этом позволяет добиться схожей (а зачастую даже большей) гибкости. Где здесь создание проблем? Налицо устранение некоторых проблем сложности, присущих другим системам типов.
Монады и функторы пришли в программирование из теории категорий, и, действительно, монады изначально были призваны решить проблему языка Хаскель, хотя и никак не связанную с алгебраическими типами данных: проблему работы с IO в чистом функциональном языке. Только спустя некоторое время нашлись многие другие применения этого полезного в хозяйстве, хм, паттерна. Оказалось, что монады — это остроумный способ решения многих других проблем, не связанных с IO. Просто ещё один способ композиции вычислений, как и функтор, и аппликативный функтор, и всё в таком духе. Больше способов композиции — больше возможностей писать композабельные системы — налицо loose coupling.
Разумеется, это всё, вероятно, не попадёт в мэйнстрим ещё очень долго. Отчасти из-за высокого порога вхождения, отчасти из-за того, что бизнес предъявляет несколько отличные от внутренней простоты требования. Бизнесу нужна лёгкость. Лёгкость замены и обучения разработчиков, доступность инструментов и так далее. Остроумных решений этой проблемы теория категорий нам, к сожалению, пока не предложила.
Есть примитивные типы, которые имеют только один экземпляр. Есть их суммы (объединение множеств значений) и произведения (декартово произведение множеств значений). Есть параметрический полиморфизм: Bool не паметризован ничем и живёт сам по себе, Maybe a параметризован типом элемента. Всё. Больше в ADT нет ничего. Это намного меньше, чем то, что есть в системах типов классических ООП-языков, и при этом позволяет добиться схожей (а зачастую даже большей) гибкости. Где здесь создание проблем? Налицо устранение некоторых проблем сложности, присущих другим системам типов.
Монады и функторы пришли в программирование из теории категорий, и, действительно, монады изначально были призваны решить проблему языка Хаскель, хотя и никак не связанную с алгебраическими типами данных: проблему работы с IO в чистом функциональном языке. Только спустя некоторое время нашлись многие другие применения этого полезного в хозяйстве, хм, паттерна. Оказалось, что монады — это остроумный способ решения многих других проблем, не связанных с IO. Просто ещё один способ композиции вычислений, как и функтор, и аппликативный функтор, и всё в таком духе. Больше способов композиции — больше возможностей писать композабельные системы — налицо loose coupling.
Разумеется, это всё, вероятно, не попадёт в мэйнстрим ещё очень долго. Отчасти из-за высокого порога вхождения, отчасти из-за того, что бизнес предъявляет несколько отличные от внутренней простоты требования. Бизнесу нужна лёгкость. Лёгкость замены и обучения разработчиков, доступность инструментов и так далее. Остроумных решений этой проблемы теория категорий нам, к сожалению, пока не предложила.
Благодарю, очень в тему — вчера вечером пролистал последние главы книги «Изучай haskell во имя добра» ибо начиная с функторов только ничего не понял, статья помогла немного прояснить картину
В GHC 7.8 решились наконец сделать аппликативный функтор суперклассом монады. Решение логически очевидное но архитектурно радикальное и разрушающее обратную совместимость.
Это нововведение Haskell 2014. www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
let foo = "oчень"
foo' = "названы"
baz = "беспорядочно"
bar = "функции"
quux = "сложно"
bar1 = "потому"
Было foo quux следить за кодом bar1, что bar foo' baz.
А чем отличается функтор от указателя на функцию из Си? Показалось, что это примерно тоже самое.
Проблема в Си с функторами не в том, чтобы найти их, а найти КАК с ними работать. Нам надо найти такую функцию
что если
то соблюдались при любых допустимых «х»:
function fmap (f, x) {...}
что если
function id (x) {return x}
function composition(f, g, x) {return f (g (x))}
то соблюдались при любых допустимых «х»:
fmap (id, x) == id (x)
fmap (composition(f, g), x) == composition(fmap(f,x), fmap(g,x))
Sign up to leave a comment.
Зачем нужны все эти функторы и монады?