это так страшно?

и делать лифт на лифте и лифтом погонять?

У тебя обычно больше пары слоев не будет, в чем проблема?

Да и я хочу исследовать идею монадных морфизмов, о которых Кметт недавно выступал, чтобы лифтов не было

можно подробнее?

ну вот с фриер бесплатно можно монаду сделать

Все эти extensible effects не думают о двух вещах, о производительности и о ContT

А соответственно остаются игрушками

Все эти extensible effects не думают о двух вещах, о производительности и о ContT

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

Все эти extensible effects не думают о двух вещах, о производительности и о ContT

а о ContT, много им пользуются?

Компилятор умеет мономорфный StateT преобразовывать практически в код, который делается императивными компиляторами.

Всякие freer решили проблемы с печальной асимптотикой, но это не дает raw performance, это асимптотика

а о ContT, много им пользуются?

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

но я думаю Киселев когда-то допилит свою идею

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

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

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

а какая идея не ограниченная?

а вы что думали?))) https://gist.github.com/gcanti/4edc2c46b37fb86cdf1234469d9734cc

а какая идея не ограниченная?

transformers

а mtl?

или фандепы это оверхед?

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

А что значит "алгебраические" эффекты? Выросшие не из IO?

mtl, monan-classes и т.п. это все трансформеры

просто более высокий интерфейс

а трансформеры могут больше одного ридера?

А что значит "алгебраические" эффекты? Выросшие не из IO?

Это когда ты описываешь алгебру эффектов как что-то с кайндом * -> *, а потом запихиваешь это в free/freer и получаешь монаду.

Алегбра эффектов описывает операции, которые ты можешь делать.

а трансформеры могут больше одного ридера?

Да

@xgrommx хоть 100

ты ж руками в нужный уровень лезешь

mtl делает это за тебя через fundeps оттого ограничение

ether,m-classes через теги или аналог

поэтому там проблемы фундепов нет

а так у трансформеров проблема это скорость, если стек глубокий

что возможно решает Monad morphism

Как раз скорость у трансформеров это их главное достоинство, потому что компилятор хорошо умеет их оптимизировать. А делать их глубокими просто не нужно, почти все эффекты коммутативны и их можешь объединять

Имеет смысл делать, например, два слоя StateT, если один под ExceptT, а другой над.

А если они оба под, или оба над, то взять и объединить

в сравнении с другими решениями - дп

но это те решения ещё более медленные

Что ты себе представляешь быстрее?

Это final encoding

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

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

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

и он получается зависим от глубины стека +- инлайн

Ребят, кто какую IDE пользует под haskell?

Вскод + хаскеро(интеро), юзабельно, но не скажу, что доволен прям всем

Я IDE не использую вообще. Раньше стоял ghc-mod на Atom, но я его отпилил, потому что полусекундная задержка и н перестал работать после какого-то обновления системного GHC

ну а редактор кода какой лучше? Я пробовал notepad++, но как-то не в восторге...

лоол

http://haskell.github.io/haskell-mode/

vscode + haskell-ide-engine, hfm

а про atom есть отзывы?

медленный

vscode + haskelly, но юзал только на маленьких проектах

idea + haskforce, худо-бедно работает (с комплитом частенько беда)

Лучше vs code

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

Подсветка синтаксиса для Haskell там есть

а про atom есть отзывы?

Atom. Всё хорошо. Запускается дольше, чем vs code, остальное тормозит одинаково и уже не из-за редактора

Подсветка синтаксиса для Haskell там есть

а ещё есть что-нибудь?:) чтобы снизить кол-во обращений к ghci в соседнем терминале

кстати, подсветка хромает

по-крайней мере на vim 7.4

> чтобы снизить кол-во обращений к ghci Все эти Intero и прочие приблуды не работают с проектами хотя бы несколько сотен файлов

Да и GHCi там себя не восторг как показывает

stack build --file-watch и вперед

stack build —file-watch —fast

даже stack build —test —file-watch —fast —pedantic

Ну да.

--pedantic turns on -Wall -Werror for GHC (all warnings on, and warnings treated as errors)

Я это в .cabal-файле включаю

А есть какой-нибудь -Wall-except-orphan-instances? И вообще, что за история с орфанами, что их так компилятор не любит?

ну как бы объявление в одном файле, а докручивания всякого в другом как-то не логично

OPTIONS_GHC -Wno-warn-orphans

в заголовок

из него любят т.к. они легко могут привести к коду, который неадекватно ведет себя в runtime

если разные инстансы применяются одновременно

https://www.youtube.com/watch?v=hIZxTQP1ifo

^ Почему нужно любить instance coherence