и bytestring и vector

там вообще inlineIO

чтобы их использовать не нужно знать как работает unsafePerformIO

и пока сам не вызваешь всё ок

ReaderT, конечно, каноничнее, но в данном случае не даёт никаких плюсов, а только проблемы

а вообще лучше так, почему нельзя использовать unsafePerformIO ?

название как бы намекает

можно, но там же внутренний голос, ему доводы нужны

Ну тащемта окружение можно менять, так что совсем канонично-ортодоксально getEnv

На мой взгляд важный довод. Если название функции говорит, что она unsafe, то код без неё лучше.

не катит

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

названия это очень важно

Ну тащемта окружение можно менять, так что совсем канонично-ортодоксально getEnv

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

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

названия это очень важно

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

не надо так

unsafe = не пользуйся, не зная зачем и как работает

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

Я б еще NOINLINE добавил к переменной

да

это обязательно

вот это отличное замечание

там вообще inlineIO

accursedUnutterablePerformIO

ну там алиас

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

@astynax не знаю что ты меня пугал с формочками, я на Люсе с type Form e a = HtmlT (Reader FormEnv) a собрал тут на коленке. вроде хватает :)

unsafe у unsafePerformIO т.к. через него можно сделать unsafeCoerce

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

с safe функциями этого не должно быть возможнр

т.к. система типов должна быть sound

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

Кое-что я про эту функцию всё же знаю. Не достаточно для того, чтобы использовать, но достаточно, чтобы не использовать.

и что же вы знаете?

что она плохая

и что почти всегда можно обойтись без неё

(я очень не люблю когда люди говорят "это плохо, потому что это плохо", поэтому просто так не отстану)

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

чем она плохая?

вообще-то в программировании идеология это всё

какие трейдофы мы получим если обойдёмся без неё

вообще-то в программировании идеология это всё

вообще-то нет

вообще-то нет

вот и поговорили

можно конкретно в данном случае

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

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

а тупые то конечно и там и везде

можно конкретно в данном случае

я не знаю

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

поддерживаю этих ребят

ну я точно тупой

это конечно в blah

в общем использование unsafePerformIO для создания топ-левел констант инициализация которых в IO это один из немногих валидных юзкейсов

естественно с uninline

noinline

(тупой Т9)

но константа действительно должна быть константой

это хуже reader тем, что нету функции local

так же тем что по типу такого поведения не видно

из плюсов, что композить такие функции проще

учитывая, что это используется для отладки - не платить трейдоф за ReaderT просто так - вполне нормально

учитывая, что это используется для отладки - не платить трейдоф за ReaderT просто так - вполне нормально

преждевременная оптимизация?

господи

вы на хаскеле пишете, хеллоу

надо различать преждевременную оптимизацию и правильное проектирование

надо различать преждевременную оптимизацию и правильное проектирование

Использование ReaderT на сколько мне известно стандартная практика

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

Использование ReaderT на сколько мне известно стандартная практика

как и неиспользование

соглашусь

ERROR: S client not available

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

Может и вырвана, но ботлнек это (почти)всегда ио, а не вот это вот.

делать ReaderT на любую константу (или runtime константу конечно можно)

Может и вырвана, но ботлнек это (почти)всегда ио, а не вот это вот.

только если IO это ботлнек в ТВОЁМ приложении

но это же почти всегда

Почти всегда в каких задачах то? В компиляторе? Или в рейтрейсере? Или в игрушках (разве что IO с gpu) ?

во многих

тут-то ботлнек при чем?

ReaderT Conf имеет смысл если зависимость от Conf это важная часть приложения

кстати есть веселая либа hflags

там все радостные практики связаны, TH, сборка инстансов в Main, unsafePerformIO

unsafe у unsafePerformIO т.к. через него можно сделать unsafeCoerce

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

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

я буду спорить

идеология не только приемлима, она еще и нужна

не нужна, нужна аргументация нормальная и доводы

Если нет идеологии, то получается c++

Без нее можно скатиться в локальные максимумы слишком легко. Если адекватно взвестить все за и против, можно прийти к решению, которое в данном контексте наилучшее. Идеология может (а хорошая - должна) привести к качественным прорывам

А если есть — эльм

Например, можно было использовать unsafeCoerce потому что так быстрее и "I know what I'm doing", а можно было придумать Coercible

Ну и собственно вариант с unsafeCoerce и привел к тому, что до ролей и Coercible у нас GND был subtly broken

Или еще пример. Если руководствоваться только практикой и юзкейсами, можно взять и придумать stack, а потом страдать с его снэпшотами. А можно до последнего добиваться нормального солвера и придумать cabal new-build с nix-style storage

ЧТД

Практики можно тут спрашивать, если что. Мы хоть посремся

Мне кажется, что @qnikst и @int_index понимают под идеологией разные вещи

а вы при разработке используете репл?

немножко

немного, т.к. полноценно тулинг не позволяет

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

немного, т.к. полноценно тулинг не позволяет

а можешь подробнее описать?

я просто для запуска м проверки простых вещей и быстрого ребилда использую

ну я тоже для проверки простых вещей

хотел бы уметь копировать определения в файл и обратно

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