постараюсь разобраться 👍 а чем package/lens отличается от package/generic-lens ? если в двух словах. Для человека, который ни с тем, ни с тем не знаком

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

Инфраструктура на высоте

иде-релейтед инфраструктура для хаскеля, упрощенно говоря, отсутствует

Да я не только про иде, сборка тоже так себе. Стэк этот блин

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

Я наверное в один момент окончательно от этого устану и возьму никс

там тоже настрадаться придется

Что стоит знать прежде чем попробую?

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

Стоит знать, что в чатике есть люди, склонные драматизировать

У никса есть какая-то интеграция со стаком

Может вместе они будут лучше

ну она для того чтоб нехаскельные зависимости никсом ставить

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

Нет бы пересобрать только что сломано и от него зависящие

А 200 зависимостей, среди которых плюсня, у меня долго собираются

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

Как это вообще происходит? Почему что-то ломается?

можно удалять не весь stack-work, а по частям

200 зависимостей должны быть не в stack-work, а в глобальном ~/.stack (который тоже можно убивать по частям)

А зачем столько зависимостей?

Что они делают для проекта?

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

Что они делают для проекта?

Я вместе с транзитивными считаю

Все что собирает стек короче

А зачем столько зависимостей?

200 зависимостей — вполне нормально для среднего проекта. это же включая транзитивные

200 зависимостей должны быть не в stack-work, а в глобальном ~/.stack (который тоже можно убивать по частям)

Какая разница где они, если они ломаются...

А как грохать частями?

Наверное, нам на проекте очень везет.

Допустим у меня стеком собран lens и он сломался. Что удалять?

lens просто для примера

А зачем столько зависимостей?

это шутка что-ли? какой-нибудь сервис на хаскеле будет от сотен пакетов зависть просто чтоб привет мир отвечать

Там же ещё какой-то package db, нельзя наверное просто удалить

А как грохать частями?

что именно сломалось? вываливается сообщение про какой-то конкретный файл?

это шутка что-ли? какой-нибудь сервис на хаскеле будет от сотен пакетов зависть просто чтоб привет мир отвечать

Нпм!

что именно сломалось? вываливается сообщение про какой-то конкретный файл?

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

Хех, hie, как никто другой помогает хасклю избежать успеха

Хех, hie, как никто другой помогает хасклю избежать успеха

?

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

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

Avoid success at all cost - глобальный мем же

Хех, hie, как никто другой помогает хасклю избежать успеха

почему?

Если убить конкретную so то стек корректно пересоберет её?

Если убить конкретную so то стек корректно пересоберет её?

её или каталог, её содержащий. в общем, проблема уровня 1 пакета, а не 200

почему?

Потому что людям как-то сложновато его собрать и заставить работать?

её или каталог, её содержащий. в общем, проблема уровня 1 пакета, а не 200

а не проще stack exec -- ghc-pkg unregister --force <имя сломанной либы>

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

а не проще stack exec -- ghc-pkg unregister --force <имя сломанной либы>

вряд ли

Потому что людям как-то сложновато его собрать и заставить работать?

ну, мне на днях удалось без проблем на Ubuntu 16.04 поставить через stack --stack-yaml=stack-8.2.2.yaml installработает, радует

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

Ну так это же стек-ворк сносит

И потом все с нуля собирать

https://github.com/nmattia/snack

инкрементальная сборка с никсом

не тестилась на реальных больших проектах

Ну так это же стек-ворк сносит

ещё и ~/.stack

Вообще счастье!

Перекачивать гхц ещё

гхц вроде оставляет

ты уже с серокел же?

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

А подскажите, в Elm есть bigdecimal или что-то подобное?

ну, мне на днях удалось без проблем на Ubuntu 16.04 поставить через stack --stack-yaml=stack-8.2.2.yaml installработает, радует

Так-то и у меня все собирается, но за последние пару дней уже второй человек говорит "да ну его нафик", и я прекрасно понимаю почему.

я пока не понял 😏

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

Pair?

Pair?

вместе собраться или hangout/whatever + ssh

и насироить

Если рассматривать всевозможные экземпляры класса лист, как объекты, а функции над ними как стрелки и т.д. это является категорией ?

Я сейчас читаю про функтор. Функтор отображает категорию в категорию. Вот и пытаюсь понять, если у меня определен функтор для листа, то что является категориями.

Если рассматривать всевозможные экземпляры класса лист, как объекты, а функции над ними как стрелки и т.д. это является категорией ?

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

Если функции образуют категорию, то что в ней морфизы?

Если функции образуют категорию, то что в ней морфизы?

Функции

Я сейчас читаю про функтор. Функтор отображает категорию в категорию. Вот и пытаюсь понять, если у меня определен функтор для листа, то что является категориями.

хаск -> хаск

Если функции образуют категорию, то что в ней морфизы?

функции высшего порядка

Я сейчас читаю про функтор. Функтор отображает категорию в категорию. Вот и пытаюсь понять, если у меня определен функтор для листа, то что является категориями.

функтор "список" отображает объекты a из Hask в объекты [a] из Hask, и стрелки a->b из Hask в стрелки [a]->[b] из Hask. То есть это функтор Hask -> Hask (эндофунктор)

Если функции образуют категорию, то что в ней морфизы?

Объекты вторичны в определении категории, МакЛейн говорит их можно выкинуть вообще. Так что именно правильный класс морфизмов с правильной композицией образует категорию

Hask .как его следует понимать?

Hask .как его следует понимать?

в гугле всё есть

в гугле всё есть

Он там найдёт, что Hask не категория и обидится

Объекты вторичны в определении категории, МакЛейн говорит их можно выкинуть вообще. Так что именно правильный класс морфизмов с правильной композицией образует категорию

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

морфизм f это морфизм между чем и чем, если объектов нет

объект — тождественный морфизм

морфизм f это морфизм между чем и чем, если объектов нет

Ну самое начало маклейна. Так как объекты один к одному сопоставляются с айдентити морфизмами, можно считать, что у тебя есть класс морфизмов и функции dom и cod, возвращающие морфизмы из этого выделенного подкласса