MK
куда(
в окамл
Size: a a a
2020 December 03
MK
а ты что подумал
AV
В расте кажется тоже норм
DB
чтобы можно было написать
module Bar where
module Foo { ... }
с тей экосистемой, что уже есть звучит как плохая идея. Вообще так себе идея имппортить _всё_ из модуля.
DB
В расте кажется тоже норм
Да, там есть
IK
с тей экосистемой, что уже есть звучит как плохая идея. Вообще так себе идея имппортить _всё_ из модуля.
Скажи это джаве
JS
Ну я же так понимаю, для таких случаев и есть екстеншеньі, чтобьі не занести в стандарт лишнего?
мне нравится мысль @A64m_qb0 о том, что расширения существуют, чтобы менять язык, не вызывая сопротивления всяких мутных консерваторов
AV
Не вижу проблем для этого в экосистеме
AV
Просто такую штуку нужно в компиляторе поддерживать
G
А в кабал файле можно поменять версию per-project, чтобьі haskell-language-server такое не писал?
JS
чтобы можно было написать
module Bar where
module Foo { ... }
ерунда какая-то. зачем?
DB
Скажи это джаве
Не хочу. Я на скале пишу. И так делаю иногдаю Но чисто из-за имплиситов котовых, который хрен знает где лежат
IK
А в кабал файле можно поменять версию per-project, чтобьі haskell-language-server такое не писал?
Есть wrapper
JS
чтобы можно было написать
module Bar where
module Foo { ... }
какую проблему это решает, которую не решают существующие модули?
DB
Не вижу проблем для этого в экосистеме
Ну понаписали ужн достаточно модулей, не связанных с собой, которые глупо импортировать вместе
G
мне нравится мысль @A64m_qb0 о том, что расширения существуют, чтобы менять язык, не вызывая сопротивления всяких мутных консерваторов
Я думал, это больше для того, чтобы из коробки бьіло меньше синтаксиса -> бьістрее компиляция
AV
какую проблему это решает, которую не решают существующие модули?
Аккуратное управление импортами и доступом к сущностям
AV
Сейчас того же уровня можно добиться делая модуль на тип
AV
Как предлагали всякие товарищи в твиттере