лучшие абстракции!

а при чем тут validated?

Можно взять Validation, он накапливает ошибки в <|> и там Monoid прокатывает

^

а

там же полугруппа нет, разве?

Semigroup e => Semigroup (Validation e a)Source# Monoid e => Monoid (Validation e a)Source

ну да

я контекст немножко упустил)))

я просто не шарю, как называется Alternative без нейтрального элемента

https://twitter.com/cartazio/status/973545338538745862?s=20 Carter is so Carter

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

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

λ> ;$(do Just name <- lookupValueName "Nothing"; info <- reify name; runIO (print info); pure []) DataConI GHC.Base.Nothing (ForallT [KindedTV a_3530822107858468866 StarT] [] (AppT (ConT GHC.Base.Maybe) (VarT a_3530822107858468866))) GHC.Base.Maybe

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

ну или qualified требовать

ладно, проверю сам, спасибо

да, lookupValueName "GHC.Base.Nothing"

lookupValueName "Prelude.Nothing"

можно пропустить лукап, если не нужна понятная ошибка λ> ;$(do info <- reify $ mkName "()"; runIO $ print info; pure []) TyConI (DataD [] GHC.Tuple.() [] Nothing [NormalC GHC.Tuple.() []] []) λ> ;$(do info <- reify $ mkName "("; runIO $ print info; pure []) <interactive>:18:4: error: ‘(’ is not in scope at a reify

tagless final это все таки очень удобно

Императивную бизнес-логику зачастую хочется абстрагировать от всего и иметь ограниченный встроенный язычок для ее описания (edls), который можно по разному интерпретировать (замокать для тестов например), для этого в хаскеле есть несколько разных путей, в том числе free/freer-монады, tagless final pattern. Представим простую задачу: мы пишем софт для некого банка и нужно описать сценарий проверки баланса всех юзеров. Нужно оповестить всех юзеров с нулевым балансом об их балансе. Сам сценарий: notifyUsersOnEmptyBalance = do usersIds <- getUsersIds for_ usersIds $ \userId -> do balance <- getBalance userId when (balance <= 0) $ do sendEmail userId "Empty balance" А в этом гисте я написал 3 рабочих (можете скопировать куда-нибудь и выполнить, никаких зависимостей не нужно) кода с реализацией этого. Внимание, на free/freer примерах есть и опредение самоих free/freer монад, в реальных проектах их обычного берут из библиотек, так что можно не учитывать их. https://gist.github.com/kana-sama/6fc14ce18bc10303a36c047fbf36a043 Первые два варианта (free/freer) генерируют из сценария ленивый список команд (ленивый в том смысле, что каждая следующая команда генерируется после выполнения предыдущей и зависит от результата ее выполнения), который затем выполняется интерпретатором. Freer-версия куда удобнее в описании, а так же намного лучше по перфомансу нежели Free-версия. Tagless final pattern версия самая короткая и удобная, но в ней мы не можем например приостановить выполнение сценария (и продолжить выполнять после).

Мы можем сделать инстанс такой что он будет эти ваши фри генерировать

и выкидывать

Можно писать в лог и делать золотые тесты

Целый дождь таких тестов

я немного не понял, а нафига все это?

офтопик: как вы относитесь к версионированию build-артефактов? это когда зависимости не инсталируются при релизе, а берутся из архива. Именно те, которые инсталились в ту среду где было тестирование

я немного не понял, а нафига все это?

то, что в посте/гисте?

да

офтопик: как вы относитесь к версионированию build-артефактов? это когда зависимости не инсталируются при релизе, а берутся из архива. Именно те, которые инсталились в ту среду где было тестирование

Мы все любим nix

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

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

и все ок пока нам не захочется это протестировать

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

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

фри и тэглес финал: - позволят подменять интерпретатор или реализацию - ограничивают язык только тем, что можно в сценариях использовать

ну давай сделаем так data App = App { GetUsersIds ::IO [UserId] GetBalance :: UserId -> IO Balance SendEmail :: UserId -> Email -> IO () }

что мы теряем?

да в принципе все

как это вообще нам помогает что-то сделать)

Чтение из базы в тестах это норма. Интеграционные тесты важнее юнит тестов. В оперденях юниттестить обычно нечего

Мы все любим nix

🤔

Чтение из базы в тестах это норма. Интеграционные тесты важнее юнит тестов. В оперденях юниттестить обычно нечего

а вот посылать сообщения юзерам во время тестов не хочется

как это вообще нам помогает что-то сделать)

ну точно так же мы отдаем в функцию некую сущность (App), которую можно мокнуть

ну точно так же мы отдаем в функцию некую сущность (App), которую можно мокнуть

а чем это тогда отличается от tagless final?

ты просто меняешь тайпкласс на словарик

Да ладно, га тестовой машине Сендмейл не настроен полюбасу....

эй, это я спросил в чем отличие

Словарик часто удобнее

#ifdef TEST...

вот это - это и есть твое решение со славарем

только этот словарик будет пробрасываться неявно

ну давай сделаем так data App = App { GetUsersIds ::IO [UserId] GetBalance :: UserId -> IO Balance SendEmail :: UserId -> Email -> IO () }

все норм, работает

#ifdef TEST...

а вот это дислайк

эй, это я спросил в чем отличие

отличие между чем и чем?

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

вот это - это и есть твое решение со славарем

Не, у тебя по m словарик подбирается, а там явно. Часто явно словарь передать удобнее

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

ну у тебя AppF это сумма зависимостей, а у меня произведение

в терминах типов

еще раз

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

можно произведение - это тэглесс финал

в моем посте оба случая есть

сумма - первые два произведение - последнее

а вот это дислайк

ой да ладно тебе, это дислайк до тех пор пока случайно из тестового энва не отправишь письмо реальному клиенту :)

про разницу между ними у меня тоже написано: Первые два варианта (free/freer) генерируют из сценария ленивый список команд (ленивый в том смысле, что каждая следующая команда генерируется после выполнения предыдущей и зависит от результата ее выполнения), который затем выполняется интерпретатором. Freer-версия куда удобнее в описании, а так же намного лучше по перфомансу нежели Free-версия. Tagless final pattern версия самая короткая и удобная, но в ней мы не можем например приостановить выполнение сценария (и продолжить выполнять после).

сумма - первые два произведение - последнее

а, я до трех считать не умею 6(

ой да ладно тебе, это дислайк до тех пор пока случайно из тестового энва не отправишь письмо реальному клиенту :)

не препроцессором же на ровном месте

CPP это дорога в ад

ну я бы #ifdef TEST error "should be mocked in test env написал всетаки

еще хуже

еще и взорвется в тестовом режиме

это же просто вопрос того каким действием проинициализировать тестовое окружение

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

как в примере выше с рекордом

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

CPP это дорога в ад

Бей СППистов, ребята!

ну да

ну вообще мне кажется пример для фримонад у @kana_sama выбран неудачно

да классический пример вроде