> {} + {} '[object Object][object Object]' > {} + {}; NaN

Ох лол, а почему так? Как вообще это работает, если в прелюдии length принимает массив

ты серъезно? length делает ограничение на Foldable

Слушай, ты что, издеваешься?

вообще тут все имплаят что у тебя локально развёрнут самый свежий хугл

Не может человек, прочитав 3 раза, не понять, что он прочитал

подержи пиво

я думал он просто про свой опыт рассказывает

рассказываю свой опыт общения с питонистами - слошь все считают, что кортеж, это такая коллекция. Причем думают, что везде так

и Foldable пары, и {} + {} объясняются одинаково: если залезть на шкаф и встать на голову, то становится всё очевидно

рассказываю свой опыт общения с питонистами - слошь все считают, что кортеж, это такая коллекция. Причем думают, что везде так

всем плевать на питонистов

эт да

http://hackage.haskell.org/package/base-4.6.0.1/docs/Prelude.html#v:length

а постарее нельзя?

Да даже если перейти по ссылке в хугле, то будет length :: t a -> Int внутри class Foldable

Вот показывает хугл неактуальный тип: https://www.haskell.org/hoogle/?hoogle=length

это какой-то пиздец. Я же ровно об этом же написал 10 минут назад

Да даже если перейти по ссылке в хугле, то будет length :: t a -> Int внутри class Foldable

ну и я про то, тем более stackage норм

http://hayoo.fh-wedel.de/?query=length

Хаю лучше работает, кароч

ты серъезно? length делает ограничение на Foldable

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

Педагогическая ошибка Хаскеля в том, что у кортежей симметричный синтаксис, но несимметричная семантика

Педагогическая ошибка Хаскеля в том, что у кортежей симметричный синтаксис, но несимметричная семантика

как и either

Если бы пара выглядела, например, как b `AnnotatedWith` a а не (a, b), то никто бы не возмущался

как и either

Да

Вот за Either лично мне обидно: все его норовят использовать для обработки ошибок, хотя есть Except

А ещё мне кажется он ущемляет левшей

Ну или точнее его инстансы

Вот за Either лично мне обидно: все его норовят использовать для обработки ошибок, хотя есть Except

вот это новости

ну так потому что Either намного проще

@astynax Except жирный больно

ээээ Except, это newtype над Either же

только с явным разделением на throwError и pure

ну так потому что Either намного проще

Вот привыкают к плохому, а потом объясняй людям, что у тебя в конкретном месте не "с ошибкой", а просто сумма

я совершенно честно не знал

ну и неудивительно, в общем-то, учитывая статьи типа {8,9,10} ways of handling errors in Haskell и вот это все

с точки зрения освоения это вообще наверное самая слабая и мутная часть языка и библиотек

сейчас рекомендуется Except, или уж эксепшны. Как то так, вроде

Псто много книг, написанных до появления Except

как эксепшны могут рекомендоваться если это небезопасно, грязно и фу-фу-фу?

@astynax type Except e = ExceptT e Identity или другой Except?

как эксепшны могут рекомендоваться если это небезопасно, грязно и фу-фу-фу?

если есть IO, то думать о них всё равно приходится

@astynax type Except e = ExceptT e Identity или другой Except?

этот

вотя и говорю, что он жирнее, чем Either

если есть IO, то думать о них всё равно приходится

this

ещё и асинхронные эксепшны есть

вотя и говорю, что он жирнее, чем Either

несильно, зато трансформер!

State сотоварищи - тоже алиасы над тпансформерами с идентити

Это уже на спичках экономия :)

и Reader, Writer, RWS

Identity - newtype, лишних оберток нет все равно

кынули тут http://starcolon.com/blog/moment-of-wtf-on-learning-haskell/index.html

Правильные тип сумма и тип-произведение это Rec и Union

они сразу N-арные

И у них нет всяких инстансов Foldable (даже по кайндам не сойдется)

Но их мешает использовать (1) синтаксический оверхед (2) небольшой performance-penalty

А еще хочется унификации higher-order произведений и сумм. Потому что раздражает иметь data Pair a b = Pair a b data Product f g a = Product (f a) (g a) data Biproduct f g a b = Biproduct (f a b) (g a b) ...

Здесь, опять же, Rec и Union подходят за счет параметризации интерпретирующим функтором.

Здесь, опять же, Rec и Union подходят за счет параметризации интерпретирующим функтором.

а где про них почитать?

Rec, я так понимаю, из vinyl

https://hackage.haskell.org/package/vinyl-0.6.0/docs/Data-Vinyl-Core.html

Union из union

А почитать нигде не могу порекомендовать хорошего, но вот в этой книжке будет https://intermediatehaskell.com/

Union из union

Ага, а еще в новом vinyl ввели CoRec, который вроде эквивалентен (но устроен по-другому внутри)

ого, здорово

CoRec - он из пакета Frames того же автора

https://hackage.haskell.org/package/vinyl-0.6.0/docs/Data-Vinyl-Core.html

сложна)

В общем я только хочу сказать, что штуковины с кайндом (k -> *) -> [k] -> * — это удачная концепцая, часто полезная, но с определенным оверхедом, который не всегда оправдан. Если бы они имели больше поддержки в языке (удобный синтаксис хотя бы), то было бы хорошо.

У них и с выводом типов история хорошая, компилятор всегда подсказывает в нужном направлении при использовании.

Т.е. хотя на первый взгляд это может показаться какой-то адок на типах, там нет линзоподобных ошибок

(k -> *) -> [k] -> * вообще прекрасно

(k -> *) -> [k] -> * вообще прекрасно

чем?

удобно в хозяйстве, можно много чего выразить

> {} + {} '[object Object][object Object]' > {} + {}; NaN

Напомнило (не WAT, но новичкам как обычно может быть в диковинку ghci> [] ++ [] [] ghci> [] ++ "" "" ghci> [] == "" True

так type String = [Char] же

Да, с этим спорить я не буду

:set -XOverloadedLists -XOverloadedStrings

и после этого вышеперечисленное вообще не обязано работать

там же ад и ужас в жавах со спрингом

это не спринг чат ребят... я думаю для таких дискусий вам сюда t.me/springframeworkio

спринг некромант :)