JS
Аккуратное управление импортами и доступом к сущностям
чтобы одни модули управляли видимостью других модулей?
Size: a a a
2020 December 03
DB
А потом приходят кованики и пишут Relude
Кстати, как оно? Стоит пользоваццо?
G
Есть wrapper
Его же и юзаю, а там можно указать версию?
IK
Кстати, как оно? Стоит пользоваццо?
Мне кажется норм
IK
Его же и юзаю, а там можно указать версию?
Не знаю, он должен сам определять
IK
Кстати, как оно? Стоит пользоваццо?
Там довольно много мелких приятностей
JS
Я думал, это больше для того, чтобы из коробки бьіло меньше синтаксиса -> бьістрее компиляция
ты же не будешь держать две системы типов — одну с линтипами, другую без. точнее, не 2, а 2^n. есть одна система типов, включающая вообще все фичи, но они фильтруются.
так что новые фичи усложняют компиляцию и кода, их не использующего
так что новые фичи усложняют компиляцию и кода, их не использующего
G
Не знаю, он должен сам определять
Вот не смог
DB
Но с одного на другое перелезать болезненно
чому?
JS
Сейчас того же уровня можно добиться делая модуль на тип
вот это лучше починить автоматической генерацией нэймспэйсов на тип. вот в Расте сразу правильно сделали
IK
чому?
Потому что там много всего, у чего нет аналогов в Prelude и библиотеках
DB
Потому что там много всего, у чего нет аналогов в Prelude и библиотеках
Так а в чём сложность? Я думал будет больно, если нет чего-то, что в стандартной есть и часто используется. Типа
<>, >>= или constIK
Так а в чём сложность? Я думал будет больно, если нет чего-то, что в стандартной есть и часто используется. Типа
<>, >>= или constЯ скорее про сложность перелезать с Relude на Prelude
DB
а, понимаю
G
вот это лучше починить автоматической генерацией нэймспэйсов на тип. вот в Расте сразу правильно сделали
А потом появляется crate::foo::bar::baz::...::SomeTrait;
AA
К, не стандарт, а текущий стейбл ghc
большая часть экстеншонов считается "стейбл гхц", кроме тех, про которые отдельно пишут что они экспериментальные, что делают крайне редко
G
А в кабал файле можно поменять версию per-project, чтобьі haskell-language-server такое не писал?
Кто-то сталкивался с таким в haskell-language-server-wrapper?
G
ты же не будешь держать две системы типов — одну с линтипами, другую без. точнее, не 2, а 2^n. есть одна система типов, включающая вообще все фичи, но они фильтруются.
так что новые фичи усложняют компиляцию и кода, их не использующего
так что новые фичи усложняют компиляцию и кода, их не использующего
Тогда зачем вообще возможность их включать/отключать?