нет я не хотел придраться, это же так и есть. Это значит что Maybe и остальные являются монадами и функторами. Разве не так?

И апликативами!

Да, и апликативами

В монадах магии нет потому что она в апликативах :3

ты понятия не имеешь что произойдёт когда ты применишь f . g . h $ x может x не используется внутри и тогда он не будет вычислен может функция мемоизируется и тогда будет вычислена лишь один раз может ещё что-то ты не думаешь в действительности о том как по шагам будет выполняться твоя логика, ты просто описываешь маппинги из одних значений в другие и комбинируешь их, всё

Можно и на C++ что-то подобное написать. ( f + g + h )(x), где + — это перегруженный оператор, который композирует функции. И такая запись (с поддержкой компилятора) тоже избавляет от необходимости думать, как там что применяется.

f . g . h ?

ещё чуть добавлю f _ = 42 g x = x + 1 h x = x * x в каком порядке будет вычислено f . g . h $ 666?

Ну я мог бы и для C++ подобное написать, там благодаря компилятору и инлайнингу тоже всё запутается

(f (g (h 666))) в таком

Вообще, что значит "порядок вычислений" ?

(f (g (h 666))) в таком

да нет, оно должно средуцироваться до 42 ещё во время компиляции зачем вычислять g(h(666)) если оно не используется?

да, так

я не понял к чему вопрос только))

ещё чуть добавлю f _ = 42 g x = x + 1 h x = x * x в каком порядке будет вычислено f . g . h $ 666?

в каком порядке произойдёт 1 событие? в любом

да нет, оно должно средуцироваться до 42 ещё во время компиляции зачем вычислять g(h(666)) если оно не используется?

не должно, но может

в каком порядке произойдёт 1 событие? в любом

ну не придирайся, там человек сказал типа когда мы композим функции мы определяем порядок их вычисления

не должно, но может

ну вот по сути я к тому и веду, что мы не думаем в категориях «сначала будет применена первая функция, потом вторая, потом третья»

мы просто композируем маппинги, как оно там внутри будет вычисляться это работа компилятора

нет я не хотел придраться, это же так и есть. Это значит что Maybe и остальные являются монадами и функторами. Разве не так?

вот есть куча каких-то штук, допустим типов есть класс этих штук, если штука относится к классу, мы иногда, если там захочется сломать язык, можем сказать, что эта штука - экземпляр этого класса чем тогда отличаются выражения "эта штука - монада" и "эта штука принадлежит классу монад"? Т.е. в общем, я согласен, что можно с большими оговорками говорить "IO - не монада, для IO есть экземпляр монады". Заметьте это отличается от поправки "IO - экземпляр монады" Здесь мы рассматриваем "экземпляр монады" как зависимую пару - тип и структура к нему, или "словарь тайпкласса" Но в большом количесте книжек по теортипам упоминается, что если вот эта дополнительная структура, т.е. "словарь тайпкласса" снабжена irrelevance, т.е. доказательством эквивалентности двух разных структур для одного объекта, что нам даёт когерентность тайплкссов, мы вполне можем говорить о "подтипах" или "подкласса" ,в этом случае Monad - это подтип "* -> *"

мы просто композируем маппинги, как оно там внутри будет вычисляться это работа компилятора

+

как IO может не быть монадой? чушь какая-то. мы же говорим «числа являются группой по сложению»

В таком случае мы вполне можем утверждать, что IO является монадой, в том случае, если построима доп-структура, требуемая определением монады для неё

как IO может не быть монадой? чушь какая-то. мы же говорим «числа являются группой по сложению»

вот вот

Поэтому я совершенно не понимаю, как можно сказать сначала "IO - не монада", а потом дополнить это "IO - экземпляр Monad"

ну не придирайся, там человек сказал типа когда мы композим функции мы определяем порядок их вычисления

В императивных языках тоже порядок вычислений перепутывается компилятором для большей эффективности

И та тоже можно было бы ожидать "42" на этапе компиляции

Ну, если те функции переписать на имп.языке

Ооооо, даже в этом чате монадные войны идут...

Поэтому я совершенно не понимаю, как можно сказать сначала "IO - не монада", а потом дополнить это "IO - экземпляр Monad"

ну окей, я утрировал конечно, просто хотел сказать что когда пытаешься объяснить что-то человеку малознакомому с хаскелем и всей этой вашей функциональщиной, нужно строго отделять свойства той же IO от того что она является монадой (реализует Monad, как угодно)

Кстати godbolt.org поддерживает haskell. Там можно посмотреть результат компиляции

> "IO - не монада, IO - экземпляр Monad" Поправка уровня "IO - не монада, IO - конструктор типа..."

😂

И та тоже можно было бы ожидать "42" на этапе компиляции

в С/С++, кстати, компилятор должен вычислять во время компиляции все выражения определенного вида (арифметические и constexpr)

И та тоже можно было бы ожидать "42" на этапе компиляции

но внезапно может оказаться что одна из этих функций печатает что-то в консоль, изменяет глобальную переменную или ещё что-то то есть функции уже не являются тупо маппингами одних значений в другие

Поэтому я совершенно не понимаю, как можно сказать сначала "IO - не монада", а потом дополнить это "IO - экземпляр Monad"

Да это просто прикол такой. Монады - это неиссякаемый источник шуток, мемов и холиваров.

Ооооо, даже в этом чате монадные войны идут...

Давайте трансформируем нашу монадовойну к исходной войне на тему "что такое декларативные языки программирования"

ну окей, я утрировал конечно, просто хотел сказать что когда пытаешься объяснить что-то человеку малознакомому с хаскелем и всей этой вашей функциональщиной, нужно строго отделять свойства той же IO от того что она является монадой (реализует Monad, как угодно)

да, говорить «main работает в идеале IO» некорректно, но «IO является монадой» — ок

И является ли Haskell императивным

Давайте трансформируем нашу монадовойну к исходной войне на тему "что такое декларативные языки программирования"

описываешь последовательные шаги вычислений = код императивный описываешь маппинги между значениями = код декларативный

Давайте трансформируем нашу монадовойну к исходной войне на тему "что такое декларативные языки программирования"

нет декларативных языков, есть декларативный код и языки, на которых можно писать декларативный код

Во!

Поддерживаю

Да, мы _можем_ писать на Хаскеле императивно.

но не хотим :-)

И является ли Haskell императивным

очевидно, на Хаскеле можно писать императивный код

как правило

описываешь последовательные шаги вычислений = код императивный описываешь маппинги между значениями = код декларативный

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

ну если уж совсем занудствовать, то можно сказать, что на хаскеле мы пишем полностью декларативную программу результатом которой является императивная программа

очевидно, на Хаскеле можно писать императивный код

только если мвар-ами обмазаться, наверно

ну да

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

хм, ну хз а если ты в голове бета-редукции делаешь?

или IORef

описываешь последовательные шаги вычислений = код императивный описываешь маппинги между значениями = код декларативный

Ну вот ты, как человек, который там в параллельном чате задрачивает линейно-зависимые с Кришнасвами, полагаешь, что "последовательные шаги вычислений" - это прям-таки так легко определимое понятие?

только если мвар-ами обмазаться, наверно

не только. есть целый вагон разных варов, в том числе MonadState и ST

а так, если рассуждать, то хаскель появился чтобы не писать императивно )

👍

Именно для этого?

ну если уж совсем занудствовать, то можно сказать, что на хаскеле мы пишем полностью декларативную программу результатом которой является императивная программа

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

в том числе для этого

а так, если рассуждать, то хаскель появился чтобы не писать императивно )

Ща ты нарвёшься, придёт А64 и расскажет тебе в который раз для чего появился хачкел

Ну вот ты, как человек, который там в параллельном чате задрачивает линейно-зависимые с Кришнасвами, полагаешь, что "последовательные шаги вычислений" - это прям-таки так легко определимое понятие?

ну ладно, я сдаюсь

Ща ты нарвёшься, придёт А64 и расскажет тебе в который раз для чего появился хачкел

на самом деле чтобы писать императивно?

Ща ты нарвёшься, придёт А64 и расскажет тебе в который раз для чего появился хачкел

@A64m_qb0 для чего появился хачкел?

ну всё ты огребаешь

Для обкатывания на нём идеек же

хм, ну хз а если ты в голове бета-редукции делаешь?

подпадает под императив

Ща ты нарвёшься, придёт А64 и расскажет тебе в который раз для чего появился хачкел

Да Хаскель это вообще шутка, а не язык. Первая же версия его когда вышла? 1 апреля 1990 года. Понимаете? Хаскель - это одна большая первоапрельская шутка. 😂

ну если уж совсем занудствовать, то можно сказать, что на хаскеле мы пишем полностью декларативную программу результатом которой является императивная программа

Вот кстати да, поддержу. Но это из серии, что "IO - не монада, а экземпляр"

подпадает под императив

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

просто разворачиваешь определение

Ну вот ты, как человек, который там в параллельном чате задрачивает линейно-зависимые с Кришнасвами, полагаешь, что "последовательные шаги вычислений" - это прям-таки так легко определимое понятие?

А это где?

А это где?

не скажу, задолбали набигать

кек

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

для императивности важно наличие исполнителя, а не порядок, имхо

для императивности важно наличие исполнителя, а не порядок, имхо

Обычно говорят о линеаризуемом стейте, так что порядок нельзя сбрасывать со счетов

Обычно говорят о линеаризуемом стейте, так что порядок нельзя сбрасывать со счетов

для целей отличения декларативности от императивности обычно не говорят о линеаризуемом стэйте

@A64m_qb0 для чего появился хачкел?

для чего появился, или для чего авторами предполагалось его применять?

😄 сам вопрос уже наброс

для чего появился, или для чего авторами предполагалось его применять?

ну наверное второе

для целей отличения декларативности от императивности обычно не говорят о линеаризуемом стэйте

Википедия утверждает, что In computer science, imperative programming is a programming paradigm that uses statements that change a program's state.

ну наверное второе

для всего, тут недостатка амбиций не было