Тут тоже задача не ясна. Что значит - удалить код? Кто-то его написал, а ты решил, что это не нужно? Или ты написал свою монаду и захотел инстансы не определять?

второе

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

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

даже с GeneralizedNewtypeDeriving

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

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

ок, просто хотел узнать как принято. спасибо.

А для нижележащего типа что определено?

А для нижележащего типа что определено?

всё определено по идее

Принято выражать монаду через эти понятия. В обратном направлении идти неправильно (хоть и можно)

Сегодня день уклончивых ответов

можно как-нибудь Applicative и Functor автоматически вывести из Monad? Хочу удалить такой код instance Applicative where pure = return (<*>) = ap instance Functor where fmap = ap . return

Разве аппликатив и функтор нынче не в зависимостях монады?

Разве аппликатив и функтор нынче не в зависимостях монады?

в зависимостях. поэтому и пришлось написать instance Applicative where pure = return (<*>) = ap instance Functor where fmap = ap . return но этот код выглядит как что-то, что можно сделать автоматически. слишком общий. Поэтому и спрашиваю, можно ли его сделать как-то автоматически.

Автоматически делать плохое?

Автоматически делать плохое?

а что плохого в таком коде?

Есть естетсвенная последовательность F->A->M и последующее должно выражаться, через предыдущее, а не наоборот

Мне не очевидно, что он сработает. А если сработает, то не очевидно, что будет работать так, как задумано.

Вот выпилят return из Monad и сделают алиасом для pure, и неправильные инстансы превратятся в тыквы

Есть естетсвенная последовательность F->A->M и последующее должно выражаться, через предыдущее, а не наоборот

ну происходит дублирование кода в таком случае. DRY помнят все же

Выражать return через pure - норма. Но не наоборот

Вот выпилят return из Monad и сделают алиасом для pure, и неправильные инстансы превратятся в тыквы

это всё равно не уберет дублирование кода. хотя уменьшит

Выражать return через pure - норма. Но не наоборот

а с <*> что делать будем? который равен ap

и заодно с fmap, который равн ap . return

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

Да блин. Это ap "равен" fmap с точностью до return

Да блин. Это ap "равен" fmap с точностью до return

равенство коммутивно

Functor'ов сильно больше, чем монад (инстансов). И выражать общее через частное - туповато

"туповато" это всё?:)

речь идёт о соблюдении DRY, всего-то

И вообще, DRY головного мозга какой-то :)

И вообще, DRY головного мозга какой-то :)

понятно. подожду, что скажут другие участники

Все Монады - Функторы, но не наоборот. Поэтому равенство как минимум по смыслу не коммутативно

Все Монады - Функторы, но не наоборот. Поэтому равенство как минимум по смыслу не коммутативно

"лошадь кушает овёс и сено"

К тому же есть ещё устоявшиеся практики.

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

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

https://hackage.haskell.org/package/base-4.8.0.0/docs/src/GHC-Base.html

return :: a -> m a return = pure

+1 за монаду из функтора

по крайней мере бойлерплейт return = pure пейсать не надо :)

А как в Vector сделать атомарное инкрементирование? succ справится? Компилятор сделает его атомарным?

хм, хороший вопрос...

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

Я сам за то, чтобы писать инстансы в "естественной" (твоей) последовательности. Но только там, где это не приводит к бойлерплейту. Например в случае Semigroup => Monoid. А вот в Applicative => Monad тебе по сути два раза приходится описывать, как комбинируется твой побочный эффект, понимаешь? Сначала для Applicative, а потом ещё в Monad. Хотя достаточно описать только в Monad, после чего сделать <*> = ap.

по крайней мере бойлерплейт return = pure пейсать не надо :)

спасибо, принято! теперь у меня это выглядит так: instance Monad where (>>=) = (тут "существенный" код) instance Applicative where pure = (тут "существенный" код) (<*>) = ap instance Functor where fmap = ap . return

^ а если писать в обратном порядке, то "существенных" кодов будет не 2, а все 4

Вот как bind с ap развязать -- это вопрос непростой.

Я бы сделал это отдельной функцией, да простят меня боги за это.

доброго времени суток! кто-нибудь знает, как сделать это без лапши? f :: Either Error Result g :: Result -> Either AnotherError AnotherResult h :: AnotherResult -> Either ThirdErrorType EndResult composed = case f of Left err -> print err Right a -> case g a of Left err -> print err Right b -> case h b of Left err -> print err Right result -> pure result

каким-таким?

"от стека только проблемы, берите кабал-инстале"

Монада же

Монада же

Тип ошибок разный

Именно

можно как-нибудь Applicative и Functor автоматически вывести из Monad? Хочу удалить такой код instance Applicative where pure = return (<*>) = ap instance Functor where fmap = ap . return

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

Ну написать комбинатор, который ошибку обобщенную принтит

Монада же

Же, но надо пользоваться fmapL из errors чтобы всех в один тип свести.

И все делать через него в монаде Either

"от стека только проблемы, берите кабал-инстале"

можно ссылкой на цитаты, а не вольную интерпретацию?

А как в Vector сделать атомарное инкрементирование? succ справится? Компилятор сделает его атомарным?

кажется, я вспоминал эту статью https://codeburst.io/the-haskell-concurrency-primitive-shootout-538c21993f1c правда, здесь нет ничего про векторы, поищу ещё

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

тут есть какие-то подводные грабли, почему так нельзя делать всегда автоматически — считать определенным Applicative и Functor, если написан Monad?

блин нахрена это дерьмо генерирующее кабал

Например так.

fmapL звучит вроде логично

тут есть какие-то подводные грабли, почему так нельзя делать всегда автоматически — считать определенным Applicative и Functor, если написан Monad?

по-моему обратный вариант (который отстаивал @astynax) наоборот может привести к проблемам, вплоть до того, что liftA2 /= liftM2 и т.д.

тип ошибок разный, но везде Either, ошибка слева и ее можно (и нужно) печатать

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

Но тогда получается в каждом месте надо вставлять fmapL show, чтобы тип стал string везде. С этим все ясно. А есть ли способ объединить эти 3 типа ошибок в 1 и отметить эти функции как Either UnionError блаблабла?

тут есть какие-то подводные грабли, почему так нельзя делать всегда автоматически — считать определенным Applicative и Functor, если написан Monad?

циклы

Всё равно fmapL

можно случайно реализовать Monad через applicative

если не свое делаешь

а если свое то можно 5 строк скопипастить

Или сами функции завернуть чтобы сразу правильный тип имели.

Например так.

там нету ни одного слова про стек

попрошу не приписывать мне свое странное понимание моих соов

Не можно, это 3 функции из разных библиотек

А как в Vector сделать атомарное инкрементирование? succ справится? Компилятор сделает его атомарным?

возможно, Vector выиграл в 1-нитевом режиме

там нету ни одного слова про стек

Про про другой инструмент есть, после чего последовал очередной срач.

а почему я считаю hpack говном и что в нем хорошего, я там полчаса расписывал

а если свое то можно 5 строк скопипастить

просто вот этот копипаст и раздражает. и возможность ошибиться в копипасте, и сделать liftA2 /= liftM2, или даже fmap /= ap . return. Но я мысль понял, что ж, придётся значит оставить так.

f :: Either String String f = undefined g :: Result -> Either Int Int g = undefined h :: AnotherResult -> Either (String, Int) (String, Int) h = undefined withError :: Show e => Either e a -> (a -> b) -> IO b withError (Left err) f = print err withError (Right a) f = pure $ f a composed = do a <- withError () (const f) b <- withError a g withError b h На компиляние или работоспособность не проверял, но идея должна быть понятна UPD: Исправил комбинатор.

возможно, Vector выиграл в 1-нитевом режиме

это не удивительно все остальные имеют оверхед на синхронизацию или атомарность

а почему я считаю hpack говном и что в нем хорошего, я там полчаса расписывал

А мог бы и не рассказывать, если бы первый наброс не был таким едким.

А мог бы и не рассказывать, если бы первый наброс не был таким едким.

не мог конечно, чтов первый раз разговор про hpack был