YP
Скала и контрвариативность. @odomontois наверняка знает почему одно лучше другого.
Size: a a a
2021 February 08
Oℕ
не
JS
наверно, libpq просочилась из postgresql-libpq, у которого сборка скриптом-таки https://github.com/haskellari/postgresql-libpq/blob/master/Setup.hs
KV
В общем я просто почистил мусор в никсе, он удалил эту директорию с lipq, и всё поехало как надо
YS
выглядит оч похоже
Oℕ
в скале нет механизма, чтобы сделать нормальные открытые семейства
JS
Там всё правильно написано, без никса
ах, оно смотрит в выхлоп программы
pg_configOℕ
а это сравнение вообще не очень адекватное, там написан разный код, и мотивация совершенно некорректная
KV
Клятые сишные библиотеки!
DB
Чото лол, всегда в тайппараметры тащить лишнюю букву лучше, чем не тащить
Oℕ
выглядит оч похоже
тут проблема в том, что ATM (abstract type member) корректнее сравнивать скорее с existential types ,чем с type family
и если ваш тип, содержащий ATM будет использоваться в type class-like роли, вы всё из-за отсутствия когерентности не можете получить подтверждение, что в двух местах Env будет одинаковый для одного F
и если ваш тип, содержащий ATM будет использоваться в type class-like роли, вы всё из-за отсутствия когерентности не можете получить подтверждение, что в двух местах Env будет одинаковый для одного F
JS
Чото лол, всегда в тайппараметры тащить лишнюю букву лучше, чем не тащить
по-моему, наоборот
DB
по-моему, наоборот
Ну так эта картинка так говорит
DB
Глупость, конечно
Oℕ
но тип, в котором Env как тайп-мембер может быть "уточнён", чтобы превратить его в параметр.
Разница будет только в том, насколько быстро будет ломаться поиск инстансов
Разница будет только в том, насколько быстро будет ломаться поиск инстансов
Oℕ
ага, то есть это все еще как фандепы, хоть и с синтаксисом семейств
Да, я уже упоминал в простыне про имплиситы, что все параметры работают как фандепы во все стороны
Oℕ
(на самом деле нет)