Alexander
и монады потом, в их математическом смысле, для связи computations с другими computations
Alexander
я кстати не знаю с чего разговор начался, может я оффтоплю
Alexander
просто это было давно и плоские модули и вся фигня
Alexander
точно так же как forM, forA
Влод
ну ок, был бы он map
Alexander
и?
Alexander
Prelude Data.List> (/) <$> sum <*> genericLength $ [1,3,5] 3.0
Alexander
вот пример для (-> a)
Alexander
не прям такое, но для функций принимающих одно и тоже значение на вход такая штука часто пишется
Alexander
так же как и map для Either и Maybe
Влод
вопрос в том зачем его обобщать. понятно что ты теперь можешь сделать более удобную функцию для любого функтора, типа mkSmth = fmap myFun
Alexander
ну например загляни в Vynil или прочие линзы
Alexander
vynil
Alexander
плюс, тут я пример в чятике не приведу
Aleksei (astynax)
> зачем его обобщать потому что можно
Aleksei (astynax)
А в Elm - нельзя
Alexander
но иметь код вида data Blah (f :: * -> *) a = ...
Alexander
вообще вот базовые линзы на этом построены
Alexander
про обобщение
Alexander
траверсалы уже на applicative
Alexander
далее
Влод
А в Elm - нельзя
очень много где нельзя. но в основном всё неудобство сводится к тому что приходится писать List.map и тип напрягает эта эксплисивность редко ситуация что прям дважды нужно написать функцию чтобы она работала с 2мя разными функторами
Влод
ну правда так скорее от того что либы не пишу
Alexander
например у тебя есть: instance [safe] (Functor f, Functor g) => Functor (Compose f g) -- Defined in ‘Data.Functor.Compose’
Aleksei (astynax)
Так проблема в том, что не имея обобщенного функтора я не смогу написать один раз библиотеку, подходящуюю для любых функторов
Aleksei (astynax)
Та же фигня с аппликативом
Alexander
как это будет выглядеть в без класса типов
Aleksei (astynax)
Именно поэтому в Elm трэш, угар и неполный набор базовых функций от коллекции к коллекции
Alexander
есть ли какая-то гарантия наличия Functor если у меня есть Monad или Applicative?
Alexander
если нету классов типов и обобщения
Aleksei (astynax)
mapM, concatMap, foldMap - вот эти все комбинаторы писать каждый раз для любого подходящего типа? Это и долго и error prone (мало ли как там взбредет автору очередной либы map реализовать)
Влод
Именно поэтому в Elm трэш, угар и неполный набор базовых функций от коллекции к коллекции
так в хаскеле то же самое. имплементация каждый раз для fmap разная
Aleksei (astynax)
fmap разный, а вот комбинаторы один раз написаны
Влод
переписывать пришлось бы
Alexander
имплементация для fmap, но не для комбинаторов
Vasiliy
ну да
Aleksei (astynax)
fmap, это "интерфейс". Его надо реализовать (или вывести). Это позволит "писать на интерфейсах, а не на реализациях" - одна из основных best practices в ООП :)
Aleksei (astynax)
Aleksei (astynax)
Проблема не только в функторе. В Elm я не могу сделать Map с произвольным ключем - вот это реальный фейл! Потому что нет Eq, Ord и прочих Hash
Aleksei (astynax)
И вот отсутствие тахих приземлённых тайпклассов дико раздражает
Dmitry
а как там сделано?
Dmitry
как в окамле?
Dmitry
или контейнеры не полиморфные?
Alexander
а там нельзя руками словарики попередавать?
Aleksei (astynax)
В Elm только встроенные типы (примитивы) могут быть ключами и сравниваться на равенство. Даже кортежи не могут
Alexander
а понял, готовый map
Alexander
ясно
Alexander
Map
Aleksei (astynax)
или контейнеры не полиморфные?
контейнеры полиморфные по значению и "магические" по ключу - ключ может быть любого типа, но из списка возможных
Dmitry
аааа
Dmitry
ну нельзя же так.
Aleksei (astynax)
"Котята терпят, колются, но продолжают жрать кактус"
Aleksei (astynax)
Причем хэшируемость и проверка на эквивалентность есть для пользовательских типов есть уже много где и давно, но нет, Эвану виднее, поэтому в Elm нету (прямо как с Пайком в Го)
Дима
Садизм какой-то
Дима
Такой Elm точно не нужен
Aleksei (astynax)
В итоге единственны вариант - класть функцию a -> Key прямо в мапу. Либо тупо таскать в аргументе (так делают в паре либ. Пример: http://package.elm-lang.org/packages/careport/elm-avl/1.0.0/Avl-Dict)
кана
вы забываете, что Elm - не язык общего назначения, это язык под конктерный юзкейс. Без тайпклассов больно, но в 95% случаев они и не нужны. Эван просто не хочет ради 5% сильно усложнять язык, хоть прекрасно понимает, что они нужны (а жс-еры въедут в тайпклассы далеко не сразу)
Dmitry
а жс-еры въедут в elm ?
Dmitry
им и на js хорошо
кана
ну почему нет, элм намного проще js
Dmitry
ну у них должна быть какая-то мотивация, если же они уже js-еры, какая им разница, что elm проще?
кана
я сидел полгода в слаке элма, там большая часть пришла из js и хаскель не знают
кана
их мотивация - убрать undefined is not a function)
кана
пиар компания про 0 ошибок в рантайме и "как редакс, только писать проще из-за иммутабельности, паттерн-метчинга" работает как надо
Dmitry
ну, хорошо если так.
Dmitry
но с другой стороны - в окамле нет тайпклассов, а полиморфные коллекции есть
Dmitry
без хаков на уровне языка
Aleksei (astynax)
В итоге на Эльме куча вещей даже из его же юзкейса деляется ну очень неудобно
Aleksei (astynax)
Но да, "просто зато"
Arseniy
Purescript❤️
Max
а жс-еры въедут в elm ?
Опыт показывает, что матерятся, но плывут
Alexander
это опыт программирования в целом
Alexander
/me начал прослеживать тенденцию в комментариях @jagajaga : ]
Arseniy
Igor
Опыт показывает, что матерятся, но плывут
Как-то очень медленно. В JS-react чате ~3k людей, а в Elm < 100
Oleg
Привет. Какой плагин ставить на VS Code для Хаскеля, может кто посоветовать?