и фримонада к этому всему относится примерно никак.

это как когда мы хотим сделать 3 операции над списком, мы сначала создаем список x = Cons 1 (Cons 2 Nil) с тремя дырами (Cons, Cons, Nil) а потом в foldr заменяем все Cons на функцию, а Nil на значение тремя разными способами (пара (a -> b -> b, b) - это и есть интерпретатор списка) a = f 1 (f 2 z1) b = g 1 (g 2 z2) Free собствено это тоже почти список

должен себя похвалить, это по моему офигенная аналогия

а засчёт чего фри/фрир медленные?

засчет, того, что их выполнение это интепретация структуры (которая ещё и не факт, что сфьюзится) в итоге на каждую операцию делаем лишнее. Это даже в случае если у нас condencity есть и сложность не растет с длиной программы

(наверняка слова я не все верно употребил

засчет, того, что их выполнение это интепретация структуры (которая ещё и не факт, что сфьюзится) в итоге на каждую операцию делаем лишнее. Это даже в случае если у нас condencity есть и сложность не растет с длиной программы

находил статью как это оптимизировать через plate

во https://qfpl.io/posts/optimising-free-with-plated/

(вспоминает, как в 2001-ом году писал парсер rtf, и в книже Гаммы предлагалось его обрабатывать паттерном Command, и такой обработчик был написан, потом выяснилось, что какой Command не помогает, нужен полноценный контекстно-зависимый парсер, а Гамма или кто там - никогда никакого парсера не писал, зато писал книжку про паттерны)

засчет, того, что их выполнение это интепретация структуры (которая ещё и не факт, что сфьюзится) в итоге на каждую операцию делаем лишнее. Это даже в случае если у нас condencity есть и сложность не растет с длиной программы

А в случае с возобновляемыми сценариями там еще и каждый шаг, каждое ветвление записывается, чтобы при остановке сценария прокрутить все это с самого начала, не исполняя эффектов. Но зато именно интерпретация позволяет создать resumable persistable сценарии

(вспоминает, как в 2001-ом году писал парсер rtf, и в книже Гаммы предлагалось его обрабатывать паттерном Command, и такой обработчик был написан, потом выяснилось, что какой Command не помогает, нужен полноценный контекстно-зависимый парсер, а Гамма или кто там - никогда никакого парсера не писал, зато писал книжку про паттерны)

классика жанра, да

допустим, мы написали на Free парсер-генератор. 1) dsl 2) вроде подходит по семантике-примерам

3) допустим, нам полезно иногда вставить в разбор логи

4) все равно мы выбрасываем всё это, потому что парсер-генератор должен генерировать быстрые парсеры.

end of case.

Не очень ясно, как скорость парсер-генератора связана со скоростью генерируемых парсеров

ну, так free ж не генерирует этот парсер, код на free этот самый парсер и есть

Ну забейте тогда.

Все-таки, это больше для кейсов, когда много бизнес-логики.

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

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

data InstF a = One a | Many Int a | Pause a deriving (Functor, Foldable, Traversable, Eq, Show) type Inst = Free InstF one :: Inst () one = liftF $ One () many :: Int -> Inst () many n = liftF $ Many n () pause :: Inst () pause = liftF $ Pause ()

из статьи

я правильно понимаю, что здесь забыт makeFree ''

который и создаёт весь профит? т.е конструкторы написаны руками

да, все три функции можно сгенерить через makeFree ''InstF

я правильно понимаю, что здесь забыт makeFree ''

Не

То есть да

Только профит в другом :)

ну да, в якобы возможности менять способ интерпретации, не меняя, допустим, весь интерпретатор

допустим, нам нужна не пауза, а пауза с логом

я понял.

это как когда мы хотим сделать 3 операции над списком, мы сначала создаем список x = Cons 1 (Cons 2 Nil) с тремя дырами (Cons, Cons, Nil) а потом в foldr заменяем все Cons на функцию, а Nil на значение тремя разными способами (пара (a -> b -> b, b) - это и есть интерпретатор списка) a = f 1 (f 2 z1) b = g 1 (g 2 z2) Free собствено это тоже почти список

я понял.

?

это как когда мы хотим сделать 3 операции над списком, мы сначала создаем список x = Cons 1 (Cons 2 Nil) с тремя дырами (Cons, Cons, Nil) а потом в foldr заменяем все Cons на функцию, а Nil на значение тремя разными способами (пара (a -> b -> b, b) - это и есть интерпретатор списка) a = f 1 (f 2 z1) b = g 1 (g 2 z2) Free собствено это тоже почти список

только высшей абстракции) я бы назвал фри как бинарное дерево

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

для абстракции зато норм

второй день обсуждения фри

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

это про хаскель

теперь вот для этого data InstF a = One a | Many Int a | Pause a deriving (Functor, Foldable, Traversable, Eq, Show)

мы хотим добавить

Branch a a a

у нас получается?

Да

Нужно расширить ADT и интерпретатор

мне кажется надо просто пейпер автора прочитать, там и про фри и фриер http://okmij.org/ftp/Haskell/extensible/more.pdf

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

Только будет Branch (Free InstF a) (Free InstF a) a

ну что за список команд без ветвления?

ну что за список команд без ветвления?

так список ленивый

а, это ж олег

вот наш список

data T n = GetValue (Int -> n) | DoSmth String n do value <- getValue if value === 0 then doSmth1 "hello" else pure () -- ==> Free (GetValue (\value -> if value === 0 then Free (DoSmth1 "hello" (Pure ())) else Pure ()) отсюда и ветвления

черт, достаточно было бы имени

и можно сворачивать все обсуждения

черт, достаточно было бы имени

Олег Киселев?)

У нас список команд [GetValue, DoSmth1 "hello"] или просто [GetValue], второй элемент (его наличие даже) зависит от результата ИНТЕРПРЕТАЦИИ первого

окей, и?

ну что за список команд без ветвления?

вот и ветвление

в списке команд нам не нужно ветвление, нам нужно только выполнить каждую команду последовательно, причем следующую команду для выполнения мы получаем из выполнения текущией, если это зависит (то самое ветвление)

https://markkarpov.com/post/free-monad-considered-harmful.html

ну и? ? он неправ?

(заруба K.I.S.S vs. SOLID )

Зависит от требований к вашей предметной области

Всегда так: может, вам годится конкретное решение, а может и нет. Нам - годится, мы уже получаем профиты

@voidlizard что именно, парсер регулярок? Есть набор правил: если строка попадает под эту регулярок, то делай так, если по эту, то этак. Мне надо понять, есть ли в нем конфликты.

(заруба K.I.S.S vs. SOLID )

Давайте завтра про крайне статическую vs крайне динамическую типизацию поговорим, например. Тут есть тоже предмет для спора.

Александр про профиты можно? пока я слышал про: 1) не надо писать монадические конструкторы 2) можно частично менять интерпратацию (добавлять логинг)

про (1) понятно

хотя и так себе

про (2)

интересно что реально надо менять и как часто и какие реальные кейсы

ну и да, давайте про динамическую

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

это сложно. но можно.

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

это как же?

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

Что значит нетипизированно? Вывод же!

Data.Dynamic?

легко выводить, когда все типы - String

ну или Value

@voidlizard что именно, парсер регулярок? Есть набор правил: если строка попадает под эту регулярок, то делай так, если по эту, то этак. Мне надо понять, есть ли в нем конфликты.

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

и тебе интересно, не делал ли кто парсер регулярок?

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

Парсер я уже сам сделал, оказалось несложно.

Александр про профиты можно? пока я слышал про: 1) не надо писать монадические конструкторы 2) можно частично менять интерпратацию (добавлять логинг)

Ну у нас сейчас четко отделены сами языки предметной области, на которых мы пишем, как наш ресторанный сервис должен работать, от имплементации, где находятся всякие BD, HTTP, конкретные либы (для времени, для дат, для всякого такого), а также настройки конкретных внешних сервисов (invoicing services, сервисов заказа еды и проч). Из наших сценариев не видно никаких лишних деталей. Например, там не светятся API keys, не светится модель данных для БД. Мы просто оперируем нашими ADT. И еще мы можем любую чать имплементации оторвать и протестировать без нее. Не будешь же дергать реальный invoicing service в тестах. Но прелесть в том, что наши сценарии чистые, предсказуемые, и там кроме предметной области ничего нет лишнего.

Хз что с ними дальше делать.

@rblaze но надо знать, что есть противоречие. два правила матчат одну строку?

Ага.

а я такую фигню на питоне писал лет семь назад

найти инпут, который будет сматчен обоими правилами. нет ли здесь проблемы останова? не является ли ответом перебор - т.е преобразовать инпут к генерируемому виду и не натравить на него arbitrary / quickcheck ?

@catamorphism путаешься в показаниях!

проблемы останова нет

точнее может и есть с каким-нибудь pcre

@catamorphism путаешься в показаниях!

в каких?

руби vs змей

неважно

я оба успел

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