слово "частичная" не отражает всю глубину падения. лучше называть такие функции, например, недоопределёнными

днищными

λ> let x = [] λ> zipWith (+) x (tail x) []

Согласен. Но если порядок аргументов поменяется, то упадет

Согласен. Но если порядок аргументов поменяется, то упадет

вот и не надо его менять:) zip x (tail x) это вообще классика

ну раз так liftA2 (liftA2 (zipWith (+))) pure tailMay

А если надо из следующего вычитать предыдущий? Я не хочу спорить. И сам tail наверное напишу. А потом на drop исправлю :-)

А если надо из следующего вычитать предыдущий? Я не хочу спорить. И сам tail наверное напишу. А потом на drop исправлю :-)

flip (-)

А если надо из следующего вычитать предыдущий? Я не хочу спорить. И сам tail наверное напишу. А потом на drop исправлю :-)

zipWith subtract x (tail x)

про drop 1 вместо tail лучше вообще забудь

а в чем причина, почему это так серьезно?

А что, если не вычитание, а другая некоммутативная операция?

А что, если не вычитание, а другая некоммутативная операция?

ну flip же

А что, если не вычитание, а другая некоммутативная операция?

flip

ну flip же

как делать такой хайлайтинг?

как делать такой хайлайтинг?

бектики

В копилку "на забывание": в разных источниках рекомендуется разное по поводу foldr, foldl и foldl'. Кажется, все из них сходятся, что foldl не стоит использовать, а насчет foldr и foldl' мнения расходятся.

бектики

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

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

да)

В копилку "на забывание": в разных источниках рекомендуется разное по поводу foldr, foldl и foldl'. Кажется, все из них сходятся, что foldl не стоит использовать, а насчет foldr и foldl' мнения расходятся.

https://wiki.haskell.org/Foldr_Foldl_Foldl%27

про drop 1 вместо tail лучше вообще забудь

А чем плох drop 1?

А чем плох drop 1?

это попытка сделать tail "безопасным", пожертвовав инъективностью функции, то есть drop 1 [] == drop 1 [x] Думаю можно придумать конкретных примеров, где это будет приводить к проблемам, но мне и этого общего соображения достаточно

Не думаю, что потеря инъективности является проблемой

tail [x] == tail [y]

tail [x] == tail [y]

да, не совсем строго выразился. но думаю меня поняли. В любом случае продолжаю считать drop 1 плохой идеей

про drop 1 вместо tail лучше вообще забудь

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

ребят, есть линза Lens' a b и есть функция b -> Lens' a c из этого же можно как-то получить Lens' a c ?

ребят, есть линза Lens' a b и есть функция b -> Lens' a c из этого же можно как-то получить Lens' a c ?

over?

Не думаю, что потеря инъективности является проблемой

Согласен. Когда пишешь реальный код на Haskell, вообще не думаешь ни о чем таком. Просто пишешь код с инвариантами, и все. Большей проблемой, пожалуй, будет манипуляция со списками как таковыми. Потребности дропнуть что-то у меня пока не возникало. Да и вообще, предпочитаю деконструировать или фолдить

+ если надо различать [] и [_], то есть паттертматчинг

+ если надо различать [] и [_], то есть паттертматчинг

not null?

Кстати, а что если в zipWith f x (tail x) функция вдруг неленивая?

то ничего страшного

Кстати, а что если в zipWith f x (tail x) функция вдруг неленивая?

не важно. тут дело в zipWith

да, сообразил уже :-)

по делу не прицепиться :-)

про drop 1 неочевидно, что выдача [] на пустом списке и на [x] лучше чем выдача исключения на пустом

но вообще drop 1 вместо tail - вполне себе хорошая идея

ребят, есть линза Lens' a b и есть функция b -> Lens' a c из этого же можно как-то получить Lens' a c ?

например, lens (\a -> let b = a ^. lab in a ^. btolac b) (\a c -> let b = a ^. lab in a & btolac b .~ c)

btolac?

btolac?

btolac :: b -> Lens' a c

аа понял нотацию

lac :: Lens' a b -> (b -> Lens' a c) -> Lens' a c lac lab btolac = lens (\a -> let b = a ^. lab in a ^. btolac b) (\a c -> let b = a ^. lab in a & btolac b .~ c)

но вообще ты хочешь странного

я не могу придумать этому адекватное имя

подозреваю, что тебе такая линза не нужна на самом деле

внутри стейта есть поле по которому я выбираю выбираю запись из хешмапа из этого же стейта

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

но в стейте в разное время меняются это поле и хешмап

ох вау

типы сошлись

говори правильно - натянулись

это кажется невероятным когда скопипастил

да да

выелетело слово из головы

но вообще drop 1 вместо tail - вполне себе хорошая идея

а x !! 0 вместо head x как тебе?:) Это ровно тот же самый стиль, если что. Немного отдаёт питончиком (я сам на питоне пишу, так что знаю)

x !! 0 это не тоже самое

попытка рулить списком через индексы

т.е. x !! 0 и head x обладают одними свойствами

drop 1 и tail разными

drop 1 и tail разными

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

везде где f [] -> [] нормальное преобразование

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

я сам там частенько пишу zip(xs, xs[1:]), очень полезно и удобно

везде где f [] -> [] нормальное преобразование

поконкретнее бы. пример задачи

ag "drop 1" libraries/<censored>/src/AS/Json.hs 36:optionsDrop1 = defaultOptions { fieldLabelModifier = drop 1 }

мне казалось ещё где-то было

tail чаще применяется

4 hfpf

раза

В копилку "на забывание": в разных источниках рекомендуется разное по поводу foldr, foldl и foldl'. Кажется, все из них сходятся, что foldl не стоит использовать, а насчет foldr и foldl' мнения расходятся.

Так, кхм, вроде ж ясно — если свёртка в скаляр, то foldl', если свёртка функцией, которая может вернуть результат, не вычисляя второй аргумент — foldr

строгая функция foldl', ленивая по второму агрументу foldr

при желании через foldr выражается все

при желании через foldr выражается все

c бенгами

при желании через foldr выражается все

Это да, и map в том числе. Производительность только аховая может быть

ну map то в первую очередь через него выражается

> "map" [~1] forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs)

собственно через него map и выражен

при желании через foldr выражается все

Если что, то это уже метаморфичная парадигма

если что это хорошее упражнение

Data.List переписать в терминах foldr

катой их, катой

кого-то катоем обозвали

Да вроде есть такая ката уже

Да вроде есть такая ката уже

я про cata

я про cata

Слишком generic

И вообще, рекурсивные схемы — вещь полезная, но малость мозг выносят

Слишком generic

дерайвь их https://hackage.haskell.org/package/catamorphism

ну и https://github.com/Lysxia/generic-recursion-schemes

я про cata

это следующее упражнение

обычные схемки сами умеют дерайвить без этого всего

это следующее упражнение

на кодеварс есть ката про Мю/Ню)

на кодеварс есть ката про Мю/Ню)

О, кинь ссылку, плиз

https://hackage.haskell.org/package/supermonad are those... superpipes?

https://hackage.haskell.org/package/supermonad are those... superpipes?

я пейпер помню про супермонаду)

О, кинь ссылку, плиз

https://www.codewars.com/kata/folding-through-a-fixed-point

https://www.codewars.com/kata/folding-through-a-fixed-point

О, пасиб

fmap mappend . sequence есть же что-то готовое для этого?