ну может там binary blob в ответе

Binary не сильно отличается от того же aeson

и вот ещё один спросил и убежал

Твори добро, и бросай его в воду. (С)

ту в которой будет лежать executable

$(stack path --local-install-root)/bin

или билд артефакты от текущего билда

смотря какие. запусти stack path и проверь

это же не то, про что я спрашивал?

мне нужно .stack-work/build/ghc-.../cabal-../dist/...

это же не то, про что я спрашивал?

если ты спрашивал про кабал, то я подмигивающий смайлик поставил

я спрашивал про стек

$ stack path --dist-dir .stack-work/dist/x86_64-osx/Cabal-2.0.1.0

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

во, это что надо

я не знаю, что такое билд-директория. там разные артефакты и временные файлы в разные кладутся. а текущая во время сборки — это директория исходников

в общем это единственное место где можно непопорченные исполняемые файлы взять

и иногда до них нужен доступ из тестов и т.п.

чтобы не делать в 2 гюшага тесты

нестрипаные бинарники? да, ${путь к каталогу пакета}/$(stack path --dist-dir)/build/${имя пакета}/${имя программы}

кажется, единственное решение

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

если у меня есть монада сложенная из StateT + ReaderT в библиотеке и я хочу дать возможность пользовательскому коду мою монаду заворачивать StateT, ReaderT, etc то мне надо надо заворачивать свою монадку в newtype, создавать LibMonad тайпкласс и делать пачку инстансов для трансформера или можно как-то проще всё сделать?

я понимаю что мне тут хочется какие-то labelled effects, но не совсем понимаю как сейчас это в хаскеле модно делать

@irezvov Это корректный подход. Если хочется иметь возможность заворачивать свою монаду в ReadeT и StateT или ReaderT и StateT в свою монаду, то свою монаду делают как newtype и не реализовывают для нее инстансы MonadReader и MonadState. Но обычно так не хочется. Как по мне, то сырые Reader и State подходят для каких-то небольших и локальных вычислений. Например, написать одну чистую функцию, которую через State намного проще, чем вручную через передачу аргументов. А для большой архитектуры неплохо использовать Three Layers подход (это довольно модный сейчас подход, но он не использует много фич системы типов). Вообще, labeled effects сделать можно в Haskell, если очень хочется. В этом видео как раз есть пример этого. Так что можно как в Idris писать, если очень хочется. https://www.youtube.com/watch?v=soKl1IslU-I

почитал про Three Layers статейку (http://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html) и что то не особо понял их идеалогию в плане второго уровня. Для начала я не понял как они предлагают комбинировать там разные классы, не через объявление же инстанса зависящего и от того и от того? И что тогда там под капотом, final tagless? И вообще, зачем все это делается? В 2018 году все вроде перешли с unit tests на behaviour tests и мокать, например, базу данных это уже мовентон, тем более что в типичном веб-приложении, например, большая часть тестов приходится как раз на sql-логику. Собстенно, обычно мокаются только сетевые запросы (как сука долгие) и это как раз делается без заморочек с сужением ответсвенности

ну то есть нарезание эндпоинта на мелкие кирпичики это в сущности та же лапша же

я понимаю что мне тут хочется какие-то labelled effects, но не совсем понимаю как сейчас это в хаскеле модно делать

ether

@cblp_su К сожалению, ether нельзя использовать для введения большого числа эффектов. Согласно словам @int_index, GHC недостаточно умный в одном месте, из-за чего использование ether приводит к (неточная цитата): "Экспонециальному от числа эффектов времени и памяти компиляции".

@cblp_su К сожалению, ether нельзя использовать для введения большого числа эффектов. Согласно словам @int_index, GHC недостаточно умный в одном месте, из-за чего использование ether приводит к (неточная цитата): "Экспонециальному от числа эффектов времени и памяти компиляции".

Омагад, вот это фэйл

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

Омагад, вот это фэйл

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

Нужны кайнд-левел доказательства полиномиальности тайп-левела

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

К 8.6 не починят?

маловероятно что починят, и.к. это фича дающая много плюсов а нормальном случае

а ether не нормальный

Экспоненциальное время компиляции - фича?

Ну вообще да, чтобы писали уже продакшн и не выпендривались.

фича это генерация специализаций для инстансов

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

там в принципе есть что улучшать в гхц

или придумать как поиск и компрессию стека сделать линейной по сложности

или как сказать гхц не генерить специализации

о, я @bravit111 но ретвиту на комментрарий обогнал

и меня обогнал, по написанному

Так это я и ретвитил!

Мне, кстати, понравилась прошлая неделя

и кстати, никаких громких холиваров никто не развёл

это радует

@astynax страничка про редакторы как бы всегда была) https://github.com/rainbyte/haskell-ide-chart

у всех Syntax highlight = The best™ possible experience. врут же!

никто не подсвечивает нормально сигнатуры вида ffff :: t

@astynax страничка про редакторы как бы всегда была) https://github.com/rainbyte/haskell-ide-chart

Она не обновляется и вообще странная

у всех Syntax highlight = The best™ possible experience. врут же!

Просто всё остальное совсем плохо, так что подсветка ок.

стоит ли отказываться от Стокгольмского синдрома и бросать vim

стоит ли отказываться от Стокгольмского синдрома и бросать vim

"...и начинать жить" :)

стоит ли отказываться от Стокгольмского синдрома и бросать vim

да, независимо от Хаскеля

(/me не может соскочить с Emacs)

жизнь ли это?

нужна ли она мне, когда я давно уже мертв изнутри?

вообще остальные редакторы тоже через ghc-mod работают?

it depends

потому что если - да, то абсолютно пофигу

Emacs может использовать ghc-mod, а может и не использовать. Можно использовать HIE, intero и другие варианты

все те же пляски начнутся, версия либ посвежее и ghc-mod не собирается

у вас cabal не той системы

бэкенды, насколько мне известно, такие: 1. ghc-mod сам по себе не развивается 2. HIE, инкорпорировавший ghc-mod 3. intero 4. hsdev 5. ghcid?

вообще остальные редакторы тоже через ghc-mod работают?

^

у Leksah, наверно, что-то своё, но редактор 1 языка никому не нужен

на всё готовы, лишь бы не емакс

/me использует haskell-mode и cabal new -repl

спасибо @cblp_su

Лексах мёртв

да я тоже использую haskell-mode

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

но cabal не той системы меня убивает

давайте ещё yi помянем

yi нерабочий ж всегда был, в отличии от лексах

@astynax страничка про редакторы как бы всегда была) https://github.com/rainbyte/haskell-ide-chart

ну, в какую сторону копать - понять можно, я на неё сморел. но за руку не берет и за собой не тащит

вообще остальные редакторы тоже через ghc-mod работают?

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

Ну они долго работают

Пара секунд лага

Быстрее чем билд