Y
Согласна с Каной тут, list comprehension самый изящный, но не для списков не стала бы использовать, поэтому третий
Size: a a a
2021 March 28
K
Третий
AP
Это вопрос привычки же — привязка comprehensions к спискам
K
Есть 3 одинаковые по функционалу функции (тавтология, привет).
Какую бы вы выбрали? Ихмо, последняя гораздо легче читается, чем первая, но при этом более обобщённая по типам, чем вторая
Какую бы вы выбрали? Ихмо, последняя гораздо легче читается, чем первая, но при этом более обобщённая по типам, чем вторая
Monad m всегда означает Applicative m, так что аппликатив модно убрать[
Monad m всегда означает Applicative m, так что аппликатив модно убратьтам альтернатив
K
там альтернатив
А, сорян, проморгал
AP
Я бы
m a2 и m b последними аргументами сделалAP
joinWith p1 p2 as bs[
мне вообще все сигнатуры хлс генерирует, сам я уточняю только если начинается вот это вот GHC-214124124.Base.Any вместо нормальных типов
AP
Явные сигнатуры на top level — хороший тон
AA
я думаю, что лист/монад компрехеншоны лучше чем ду нотация во всех случаях кроме:
do не заканчивается return, используются байнды которые () <-
do не заканчивается return, используются байнды которые () <-
[
Ну, я понимаю, просто вот есть у меня функция без сигнатуры, я тыкаю на серую надпись сверху и сигнатура появляется
[
Я про это и говорил, что мне сигнатуры хлс сам создаёт если не надо уточнять конкретно типы из-за его ошибок
AP
Компилятор не может в смысл типовых переменных. Рукописная сигнатура позволяет этот смысл привнести
AP
a, b, c вместо a1, b2, t7 лучше смотрятся
[
поправил
AP
Зачем предикаты в конце? Это же очевидные кандидаты для частичного применения!