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

Всё хочу написать программку, которая будет брать снапшот их проекта и формировать строку для поиска (и скармливать браузеру)

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

Локальный хугл должен прокатить

ну да

но это надо ещё его иметь :)

питонячий __file__ отсутствует :(

Так модуль же может наполняться из разных пакетов

расшифруй?

ты про определения из него?

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

(но это не точно)

да ну

фигня

интересно что ghci показывает имя пакета в тех случаях, когда зависимость от него только транзитивная. Linear.Algebra.unitalRep :: (adjunctions-4.3:Data.Functor.Rep.Representable f, Linear.Algebra.Algebra r (adjunctions-4.3:Data.Functor.Rep.Rep f)) => r -> f r но как управлять этой вербозностью ghci чтоб он для всего показывал - я не знаю, может и никак.

хитро

Всем спасибо за ссылки по категориям ))

а там курс от баеса был? :)

Вроде нет

В любом случае даже если был продублируй плиз

https://johncarlosbaez.wordpress.com/2018/03/26/seven-sketches-in-compositionality/

по книжке Спивака

пасиб

https://johncarlosbaez.wordpress.com/2018/03/26/seven-sketches-in-compositionality/

А кто-нибудь новую книжку спивака и этот курс читал/смотрел? Линки много раз были, но отзывов не видел.

и ещё положительное слышал про http://www.math.jhu.edu/~eriehl/context.pdf

Я в ТК так и не смог, к стыду, но в закладках из того, что тут рекомендовали — http://telegra.ph/Materialy-po-teorii-kategorij-12-22 Из самого доступного, что я встречал — лекции Брагилевского (есть на youtube), но всё равно очень тяжело идёт.

Без понятия что там для "программистов" у Милевски, но вот нормальная серия https://arxiv.org/abs/1803.05316 со здоровыми прикладными мотивами

быстровопрос: можно ли MTL переписать на TypeFunctions вместо FunctionalDependencies?

Без понятия что там для "программистов" у Милевски, но вот нормальная серия https://arxiv.org/abs/1803.05316 со здоровыми прикладными мотивами

выше научпоп просили, Милевски к такому ближе всего

быстровопрос: можно ли MTL переписать на TypeFunctions вместо FunctionalDependencies?

его переписали даже

успешно?

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

http://hackage.haskell.org/package/monads-tf

Сабмитнул Diff, который убирает -XTypeInType из GHC.

вводящий в заблуждение анонс, мягко говоря

Без понятия что там для "программистов" у Милевски, но вот нормальная серия https://arxiv.org/abs/1803.05316 со здоровыми прикладными мотивами

Выше курс Баеса по ней и Денис про неё спрашивал :)

вводящий в заблуждение анонс, мягко говоря

Конечно, иначе ничего интересного

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

лучше бы его оставили как синоним для DataKinds и PolyKinds

Ну вот он в этом диффе и стал синонимом

это-то понятно, я про то чтоб всегда был такой синоним, а не депрекейтился

Название у него по историческим причинам, поэтому и хочется его убрать.

да, но большой проблемы тут не вижу

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

А преимущества то есть?

Да я тоже большой проблемы не вижу. Все равно в конечном итоге все эти экстеншены заменятся на -XDependentHaskell

нет

до этого итога далеко еще

я джва года такой экстеншн ещё ждать буду

Ну да. Один студент Ричарда берется парсеры термов и типов объединять. Не знает во что ввязввается наверное

последний нормальный экстеншон будет и все, больше нечего добавлять, только подчеркивания в литералах всякие Ж(((

Да не, зависимые типы можно бесконечно допиливать же.

Интеграцию с линейными там

Какой-нибудь proof erasure прикручивать к оптимизатору и т.д.

да, но крупный экстеншон-то последний

UnivalentHaskell придумают к тому времени

Ну да. Один студент Ричарда берется парсеры термов и типов объединять. Не знает во что ввязввается наверное

они там все такие

бесстрашные

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

Я правильно понимаю, что с DH семейства будут не нужны (именно с ним)?

Может раньше, я хочу этим заняться

в смысле, не нужны?

Разве они не заменятся на обычные функции от типов к типам?

синтаксически-то да, может и будут выглядеть как обычные функции

но это ж все равно семейства будут

там же вся эта коэршн-машинерия из FC остается

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

То есть если и будут, то не такие как сейчас

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

ну, в деталях не такие

Ну если все детали поменять, то что останется? И если говорить про Core, его же тоже переделывают. Хотя Coercion остаются вроде, да

ну и не будут же они убирать открытые семейства

Добавить открытые функции может 🤔

Весь адхок останется через тайпклассы

но тайпклассы с ассоциированными типами же

class Elem (a :: Type) where elem :: Type instance Elem [a] where elem = a -- тут хрень конечно, нужны синглтоны для типов какие-то что ли class Elem c => Collection c where get :: c -> Maybe (elem @c)

class Elem (a :: Type) where elem :: Type instance Elem [a] where elem = a -- тут хрень конечно, нужны синглтоны для типов какие-то что ли class Elem c => Collection c where get :: c -> Maybe (elem @c)

Maybe (elem @c) лучше, чем Maybe (Elem c)?

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

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

А чем он плох?

https://tech.yandex.ru/dialogs/alice/doc/development-docpage/ - Алиса, что такое монады?

вербозный

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