еще хуже

фри это не аст, это ленивая последовательность команд, где каждый n+1 элемент может зависить от результата выполнения 0..n

Не хотите фри монады, - можно и без них. Можно выразить предметную область типами и чистыми значениями. А потом в рантайме собирать из этого все, что вам нужно

@kana_sama как мне сделать так, что из этого кода на фримонадах сгенерировать нечто (вместе с ифами), оптимизировать, сгенерить из результата - скажем - код на си?

Александр это называется "написать программу на хаскелле"

@kana_sama как мне сделать так, что из этого кода на фримонадах сгенерировать нечто (вместе с ифами), оптимизировать, сгенерить из результата - скажем - код на си?

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

Александр это называется "написать программу на хаскелле"

❤

да, я вот пытаюсь найти это предметную область фримонад

оказывается, оно чуть-чуть в сторону и уже не область

без понятия, слишком сложный запрос для меня, я лишь расписал, почему во фри есть if, потому что судя по "во фри нет ветвления" у тебя сложилось неверное понимание того, что есть фри (еще раз, это не аст)

Александр это называется "написать программу на хаскелле"

Написать программу можно очень по-разному. Но есть требования (функциональные и нефункциональные). И тут уже нельзя просто взять и нафигачить код. То есть, можно, но через полгода можно будет его выбросить.

ну вот это не if как первоклассное значение, скажем так

он работает на этапе конструирования - если код на фримонадах что-то конструирует

но в том, что он конструирует его уже нет

если же я забыл слово "фримонада"

в общем что я знаю про фри монады: - ими можно пользоваться(никто не знает зачем) - ими можно не пользоваться - if в них работает обычный

просто сделал ADT

Написать программу можно очень по-разному. Но есть требования (функциональные и нефункциональные). И тут уже нельзя просто взять и нафигачить код. То есть, можно, но через полгода можно будет его выбросить.

Так зачем писать на фри если можно на тайпклассах?

а, ну так free и не дсл для генерации кода, это дсл для описания алгоритма (последовательности команд, в том числе и нелинейного), которая потом выполняется, а не что-то генерирует

и потом его обхожу и делаю то, что мне надо - хочу интерпретирую

хочу генерирую другой ADT

то никаких ограничений у меня нет ни на что

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

в общем что я знаю про фри монады: - ими можно пользоваться(никто не знает зачем) - ими можно не пользоваться - if в них работает обычный

Я знаю. Коллеги знают. Гонзалес тоже знает.

а, ну так free и не дсл для генерации кода, это дсл для описания алгоритма (последовательности команд, в том числе и нелинейного), которая потом выполняется, а не что-то генерирует

а для выполнения (интерпретатор) уже Cofree приходит

в общем есть мнение такое, что если вам абстракция по функтору f не нужна из Free f a, то нафиг вам в вашем конкретном случае фри-монады не нужны

мы не знаем, нужна она нам или нет

т.к. цель не получить абстракцию по функтору

в общем есть мнение такое, что если вам абстракция по функтору f не нужна из Free f a, то нафиг вам в вашем конкретном случае фри-монады не нужны

А когда бывает надо?

а получить код, который что-то полезное делает

точнее даже так - получить что-то полезное.

а получить код, который что-то полезное делает

👍

лучше , если кода при этом будет меньше

или не будет совсем

Так зачем писать на фри если можно на тайпклассах?

Пишите на тайпклассах. Не проблема. Код удовлетворяет требованиям? Окей. Читается легко, понимается, изменяется? Окей.

последние три - это чистая вкусовщина

никогда не знаешь, кому что легко читается понимается и изменяется

субъективно.

А когда бывает надо?

сходу не знаю, что-то неочевидное, типа функтора в виниле

на полуфабрикат похоже

Если нужно чистым образом заимплементить императивные по сути сценарии предметной области (взять/положить в БД, дернуть сервис...), то фри монады - правильное решение.

что думаете про ReasonML?

Пишите на тайпклассах. Не проблема. Код удовлетворяет требованиям? Окей. Читается легко, понимается, изменяется? Окей.

А ещё код специализируется и инлайнится

почему эти сценарии нельзя реализовать просто функцией?

@voidlizard в плане вообще всяких своих языков лучше юзать алгебры различные и сворачивать все единой сверткой опрелеленной через общий интерфейс https://gist.github.com/xgrommx/4c72ae9d407214deab55fe9aebc08b45#file-hrecursionschemes-hs-L83-L105

Если нужно чистым образом заимплементить императивные по сути сценарии предметной области (взять/положить в БД, дернуть сервис...), то фри монады - правильное решение.

А чем на тайпклассах то грязно?

@voidlizard в плане вообще всяких своих языков лучше юзать алгебры различные и сворачивать все единой сверткой опрелеленной через общий интерфейс https://gist.github.com/xgrommx/4c72ae9d407214deab55fe9aebc08b45#file-hrecursionschemes-hs-L83-L105

Джоб секьюрити опять же

@xgrommx а точно лучше? чем, например, просто преобразование.

ну все, я готов кибербуллить

и вот всякие переходы от ввода пользователя в ast это некий анаморфизм, а интерпретация или преобразования - некий катаморфизм

почему эти сценарии нельзя реализовать просто функцией?

Это в любом случае будут функции. У нас же ФП. Но дополнительный уровень абстракции - возможность интерпретации - позволяет делать всякие полезные штуки. Например, в интерпретаторе на каждый метод добавить логгирование. У вас в сценарии не будет лишних команд для логгирования, а логгироваться будет. Или другой кейс (реальный): сценарии возобновляемые. То есть, сценарии выглядят обычно, а вот интерпретатор умеет останавливаться и персистить промежуточные данные в БД. Можно даже сервер перезапустить.

@voidlizard в плане вообще всяких своих языков лучше юзать алгебры различные и сворачивать все единой сверткой опрелеленной через общий интерфейс https://gist.github.com/xgrommx/4c72ae9d407214deab55fe9aebc08b45#file-hrecursionschemes-hs-L83-L105

HFunctor это какой-то функтор в категории функторов

что думаете про ReasonML?

таксе

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

но и то, и другое налагает ограничения на разработчика

довольно искусственные

А чем на тайпклассах то грязно?

Много про детали реализации видно, когда на них прогаете. Много лишнего писать. Но это, конечно, нельзя померить объективно.

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

Безусловно.

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

что думаете про ReasonML?

окамл со страшным синтаксисом, со всеми вытекающими?

@kana_sama реквестирую больше примеров, где это удобно

а у Окамла красивый?

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

или заюзать Cofree как интерпретатор (где-то была статья, могу потом скинуть)

а у Окамла красивый?

не особенно, но лучше чем у ризонэмеля-то

@kana_sama я как увижу какой-то профит, сразу же внедрю

@kana_sama реквестирую больше примеров, где это удобно

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

я раньше думал у хаскеля фиговый

Окей, мы пришли к какому-то консенсусу, поэтому здесь остагавливаюсь, чтобы впечатлительных на кибербулинг не провоцировать.

но потом увидел F# и MLи

@kana_sama да, я хочу видеть, где фримонады сокращают бойлерплейт, а не увеличивают его

я раньше думал у хаскеля фиговый

нет, я так не думал

@kana_sama в идеале одно и тоже на них, и без них

HFunctor это какой-то функтор в категории функторов

ага)

@kana_sama да, я хочу видеть, где фримонады сокращают бойлерплейт, а не увеличивают его

ну там есть всякие makeFree и прочее из TH

ребят, кто говорил что-то вроде "Для каждой задачи свой язык"?

@kana_sama да, я хочу видеть, где фримонады сокращают бойлерплейт, а не увеличивают его

Они не сокращают бойлерплейт. Они сокращают сложность

@kana_sama да, я хочу видеть, где фримонады сокращают бойлерплейт, а не увеличивают его

окей, начнем с того, что DeriveFunctor (какой бы он не был медленный) генерит функтор по adt T, уже минус описание функтора. makeFree в пакете free тоже генерирует все смарт-конструкторы для Free T. Ну а Free дает еще и инстанс монады. Вручную остается писать только ровно один интерпретатор - это в прямом смысле только тот код, который реализуется за каждой командой дслки, то есть меньше и придумать нельзя С тайпклассами это будет реализация инстанса, то есть столько же кода

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

ребят, кто говорил что-то вроде "Для каждой задачи свой язык"?

в интернетах - каждый второй, но имена они часто скрывают, чтоб не засмеяли

из минусов - или писать монаду самому, или незаконно использовать Writer