да уже годы, сколько я хаскель помню, есть какое-то движение писать подлиннее

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

@A64m_qb0 а где это движение? какие-то важные люди это говорят? это в рамках движения что бы ублажить ньюкамеров или что?

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

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

против тайпклассов - в голове не укладываются

Малое количество LoC - это плохо. Ломает систему KPI.

за полную квалификацию тоже

это если в KPI есть LOC

Всегда были )

Почему Go и JS в фаворе?

да где были то?

опять же, жс должен давать меньше строк, чем go

go специально для квадратно-гнездовых людей

Схреналь?

Там где популярны LOC в KPI господствует java, а не JS или go

ну он типа скобок, только со странным синтаксисом

Ну, ява по умолчанию

Синглтон фабрики фабрик фасадов классов

ну он типа скобок, только со странным синтаксисом

По мне так го это типа питона, только с указателями и сишным синтаксисом

Хотя если подумать, и против тайпклассов гонзалес писал, и полную квалификацию продвигал он, и на адовый for-loop стиль с операторов он переходил

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

но нет, не только Гонзалес.

Синглтон фабрики фабрик фасадов классов

bean потерялся https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

но тайпклассы то чем?

Вот Диль против ТХ и дерайвингов агитирует, это ж тоже за увиличение числа строк

против дерайвинга понятно - тормоза и в компайл тайме, и в рантайме

но нужен какой-то более лучший дерайвинг, пожалуй

я вот за явные импорты. и еще я за плагины это автоматизирующие

вот на пурсе очень удобно в емаксе

я против явных импортов потому что это недосигнатуры

явные импорты улучшают форвард компатибилити

но тайпклассы то чем?

программный манифест тайпклассохейтеров это вот это вот http://www.haskellforall.com/2012/05/scrap-your-type-classes.html

явные импорты улучшают форвард компатибилити

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

сигнатуры это этот ваш бэкпэк? /me дикий, на ML не писал

нам нужен какой-то другой хаскель. куда не будут пускать психов.

в бекпаке это все тяжеловесно слишком

@A64m_qb0 как ты там говорил "Бэкпэк как разрабатывался для уничтожения стэка, так и развивается"

а какой сейчас статус бэкпака?

в 8.2.2 как-то работает, но все еще куча багов, вроде несовместимости с CPP.

у него два пользователя сейчас - автор и Кметт, так что кучу еще нарепортят

еще Остин писал что балуется

https://github.com/haskell/cabal/issues/4206#issuecomment-352053590 во

да, я вспомнил, что @int_index еще

опять злой кабал против коммэрции

https://github.com/andorp/grin

был еще репозиторий, в котором был ГРИН из jhc очищенный от остального jhc

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

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

пытаюсь читать описание бакпэка - но TL;DR - это как в окамле?

При том, что потенциально он легковеснее эмельных модулей может быть потому, что у миксинов применение "функторов" автоматическое

пытаюсь читать описание бакпэка - но TL;DR - это как в окамле?

отдаленно, разве что. не как в окамле то, что это миксины, второе поколение эмельных модулей, которых в эмелях нету. Во вторых не как в окамле потому, что раздельно не билдится, т.е. в этом смысле как в mlton-е скорее

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

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

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

генерация инстансов это как специализация темплейтов в плюсах? и как помогут модули?

не совсем. там просто зиллион бойлерплейтных иснтансов, которые отличаются типами в основном

и чтоб их руками не писать - там сишные макросы

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

Почему не победить? Если эти generic функции бэкпэком параметризовать, то их и специализировать вручную не надо

#define primMVector(ty,con) \ instance M.MVector MVector ty where { \ {-# INLINE basicLength #-} \ ; {-# INLINE basicUnsafeSlice #-} \ ; {-# INLINE basicOverlaps #-} \ ; {-# INLINE basicUnsafeNew #-} \ ; {-# INLINE basicInitialize #-} \ ; {-# INLINE basicUnsafeReplicate #-} \ ; {-# INLINE basicUnsafeRead #-} \ ; {-# INLINE basicUnsafeWrite #-} \ ; {-# INLINE basicClear #-} \ ; {-# INLINE basicSet #-} \ ; {-# INLINE basicUnsafeCopy #-} \ ; {-# INLINE basicUnsafeGrow #-} \ ; basicLength (con v) = M.basicLength v \ ; basicUnsafeSlice i n (con v) = con $ M.basicUnsafeSlice i n v \ ; basicOverlaps (con v1) (con v2) = M.basicOverlaps v1 v2 \ ; basicUnsafeNew n = con `liftM` M.basicUnsafeNew n \ ; basicInitialize (con v) = M.basicInitialize v \ ; basicUnsafeReplicate n x = con `liftM` M.basicUnsafeReplicate n x \ ; basicUnsafeRead (con v) i = M.basicUnsafeRead v i \ ; basicUnsafeWrite (con v) i x = M.basicUnsafeWrite v i x \ ; basicClear (con v) = M.basicClear v \ ; basicSet (con v) x = M.basicSet v x \ ; basicUnsafeCopy (con v1) (con v2) = M.basicUnsafeCopy v1 v2 \ ; basicUnsafeMove (con v1) (con v2) = M.basicUnsafeMove v1 v2 \ ; basicUnsafeGrow (con v) n = con `liftM` M.basicUnsafeGrow v n } #define primVector(ty,con,mcon) \ instance G.Vector Vector ty where { \ {-# INLINE basicUnsafeFreeze #-} \ ; {-# INLINE basicUnsafeThaw #-} \ ; {-# INLINE basicLength #-} \ ; {-# INLINE basicUnsafeSlice #-} \ ; {-# INLINE basicUnsafeIndexM #-} \ ; {-# INLINE elemseq #-} \ ; basicUnsafeFreeze (mcon v) = con `liftM` G.basicUnsafeFreeze v \ ; basicUnsafeThaw (con v) = mcon `liftM` G.basicUnsafeThaw v \ ; basicLength (con v) = G.basicLength v \ ; basicUnsafeSlice i n (con v) = con $ G.basicUnsafeSlice i n v \ ; basicUnsafeIndexM (con v) i = G.basicUnsafeIndexM v i \ ; basicUnsafeCopy (mcon mv) (con v) = G.basicUnsafeCopy mv v \ ; elemseq _ = seq }

порвал чат

Почему не победить? Если эти generic функции бэкпэком параметризовать, то их и специализировать вручную не надо

там тогда констрейнты надо параметром

Почему не победить? Если эти generic функции бэкпэком параметризовать, то их и специализировать вручную не надо

ну если дженерик вектора делать на бекпаке, а не на классах - да, но классы тут удобнее. Речь о том, что бекпак не может сделать из дженерик модулей специализированные анбоксед, сторабл и боксед, а эмельные модули могут, там сигнатуры применяются не один в один а с сабтайпингом

Чем классы тут удобнее?

Я пока что только путался от того, что тридцать с половиной штук названо Vector

Хорошо хоть для MVector дали название другое.

Могли бы и для класса дать CVector

А без класса еще лучше

там тогда констрейнты надо параметром

так это бекпак может как раз

ERROR: S client not available

но не факт, что это и понадобится даже

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

я про это

А без класса еще лучше

чем лучше-то? Тогда обобщенный код для любого вектора как писать?

а пишут ли такой код?

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

а пишут ли такой код?

а что, нет?

ну вот вектор алгоритмс только для MVector же

а, понял

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

Я так это себе и вижу, причем не понимаю почему неудобно

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

даже эмельные модули для такого много ручного труда требуют

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

я понимаю что это неуместный канал, но как в питоне принято делать dependency injection/global state?

используй мою либу, лол :)

какую?

https://github.com/astynax/yadic

вообще я хочу очень малого у меня в модуче Bla.stdlib есть фунция def blabla(name):

мне нужно чтобы у неё был доступ к окружению (aka Reader) в котором пара констант определены

то чтобы не было доп параметров у функции и она не была куском объекта

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

(это интерпретатор если что)

ну ты можешь ещё искать выше по стэку во фреймах :)

Так делают магический request во фреймворке Flask

жуть какая

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

Глобальная переменная, это несейфно

Надо тогда thread locals юзать

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

тредов нету, гарантировано

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

Специально обученный модуль, это класс со статическими методами