А сложение флоатов неассоциативно

то есть Sum Float и так моноид, без дополнительного инстанса для Fractional (Sum a)

я подумал об этом, но вроде бы это тут никак не влияет

а, ну да, это в обратную сторону логика

(это не говоря уж о том, что моноидные законы и с переполнением как-то не особо дружат, это же не мешает нам писать `Monoid (Product Int)`)

повод расширить стандартную библиотеку

1.5 не Num

1.5 Num

просто оно ещё и Fractional

1.5 Num

ой. я имел в виду, Num не 1.5

для 1.5 недостаточно Num

для 1.5 недостаточно Num

да, вот так

не в любой Num влезет 1.5, скажем так ?

Я поражаюсь hlint конечно. Прямо приятно что я не один такой тупой, а тупых так много что аж такие вот советы линтер встроены.

почему я сам не догадался написать "m == Just "on" а первое что в голову пришло было maybe False (== "on") m?

слишком функционально мыслишь

булева слепота

да я вроде недавно был у офтальмолога

почему я сам не догадался написать "m == Just "on" а первое что в голову пришло было maybe False (== "on") m?

Я как-то давно насобачился эксплуатировать эквалити вглубь :)

Вместо "распакуй и сравни" делаю "запакуй эталон до нужной структуры" ;)

а на плохой стиль hlint тоже ругается? скажем излишнее увлечение point-less

Я поражаюсь hlint конечно. Прямо приятно что я не один такой тупой, а тупых так много что аж такие вот советы линтер встроены.

возможно, просто этот совет было легко встроить

или вот такое, я недавно писал zipWith id [(^2), (^3)] [1, 2]

а на плохой стиль hlint тоже ругается? скажем излишнее увлечение point-less

наоборот, советует эта-редукцию и рыбок

наоборот, советует эта-редукцию и рыбок

рыбки это что?

во, кстати. Что всякие стайл-гайды говорят про if..then..else в сравнении с case..of?

рыбки это что?

монадный байнд и композиция Кляйсли в разные стороны

рыбка - >=>

(<=<) - более правильная

(<=<) - более правильная

ну, началось

ну а что? Если композишь вперед так пиши просто do

во, кстати. Что всякие стайл-гайды говорят про if..then..else в сравнении с case..of?

мой персональный гайд говорит, что case...True...False... надо заменять на if. в остальном они не пересекаются, так что и без гайда всё понятно

if как-то выделяется из остального синтаксиса. глаза режет

ну а что? Если композишь вперед так пиши просто do

приходится имена придумывать

ладно, а относительно fromMaybe и maybe?

вот между и ифом и гардами есть конфликт

Кстати, почему?

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

если со значением под Maybe надо что-то сделать то maybe, если нет то fromMaybe. good = maybe "" show bad = fromMaybe "" . fmap show

ладно, а относительно fromMaybe и maybe?

так это тоже разные вещи. fromMaybe x == maybe x id, чтобы заменить второе на первое, достаточно hlint

если со значением под Maybe надо что-то сделать то maybe, если нет то fromMaybe. good = maybe "" show bad = fromMaybe "" . fmap show

я не это имел в виду - я про замену этих функций на обороты case of и if then else

я кстати не обламываюсь делать case для мейби в монадном коде. читается лучше чем join . maybe

case норм

я и кейс и иф не люблю

если со значением под Maybe надо что-то сделать то maybe, если нет то fromMaybe. good = maybe "" show bad = fromMaybe "" . fmap show

вот такое: good' mx = case mx of Just x -> show x _ -> ""

я и кейс и иф не люблю

потому что композиционный стиль?

больше похоже на императивщину

вот такое: good' mx = case mx of Just x -> show x _ -> ""

нет, только если case mx of Nothing -> logMsg "Got nothing" Just v -> do frabulate v logMsg "frabulated"

потому что композиционный стиль?

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

Кстати а есть поинтфри аналог кейса?

\case

Кстати а есть поинтфри аналог кейса?

деструкторы (деконструкторы). например maybe, either, bool

мой персональный гайд говорит, что case...True...False... надо заменять на if. в остальном они не пересекаются, так что и без гайда всё понятно

ну они пересекаются, когда можно матчить с конкретным значением, а можно сравнить с помощью ==. Такое часто встречается, на самом деле.

вот тут например явно case пошёл бы лучше, не было бы лесенки https://www.govnokod.ru/6765

ну они пересекаются, когда можно матчить с конкретным значением, а можно сравнить с помощью ==. Такое часто встречается, на самом деле.

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

тут даже не кейс

а просто гард с elem

лучше матчить, чем сравнивать

10 матчей или elem "01234567890."?

даже не так, тут просто chislo = all (`elem` "0123456789.")

напоминаю про существование MultiWayIf

деструкторы (деконструкторы). например maybe, either, bool

ещеfoldr

даже не так, тут просто chislo = all (`elem` "0123456789.")

а разве у Char нет Ord?

0-9 же идут друг за другом в ascii

не говоря уже про Data.Char.isNumber

есть, но там точка еще, проще сделать одну проверку, а не две

напоминаю про существование MultiWayIf

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

даже не так, тут просто chislo = all (`elem` "0123456789.")

?

chislo = all (`elem` '.':['0'..'9'])

ERROR: S client not available

а разве у Char нет Ord?

? си путь

foo str = case str of [] -> error "YOLO" '.':xs -> whatever x:xs | isNumber x -> blah | otherwise -> blahblha

тут уж не говоря о том, что "1.3..44" это тоже число будет

и да, я считаю что ro-che был прав и case лучше чем несколько тел функции с матчем

несколько тел хороши, пока тела однострочные

несколько тел хороши, пока тела однострочные

и where не общий

optText "" = Nothing optText t = Just t

Вот такое ок и красиво

и where не общий

Это боль :(

я в свое время чуть не бросил изучать хаскель заглянув в ЯХТ и увидав там адовые лесенки из кейсов и ифов

я в свое время чуть не бросил изучать хаскель заглянув в ЯХТ и увидав там адовые лесенки из кейсов и ифов

помоги компилятору оптимизировать!

Беда переписывания с мультиклозов на case - несколько параметров у функции. Лишний визуальный шум от кортежей - фу

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

вам ленивость дали что-бы вы могли писать всё в where и потом в кейзах писать одну строчку

"мало матчинга, много логики" = case "много матчинга, мало логики" = клозы

Мультиклозы с общим where были бы норм ваще

мне кажется что часто много матчинга и глубокие структуры это скорее от лени написать еще один АДТ и зарание подготовить для проблемной области

Нет же, вот ты матчишь два переметра на предмет комбинаций - отличный вариант для мультиклоза

Вот у Джаспера про это https://jaspervdj.be/posts/2016-05-11-ad-hoc-datatypes.html

Нет же, вот ты матчишь два переметра на предмет комбинаций - отличный вариант для мультиклоза

ну это да

Вот! Я про такие случаи

Сам то точе часто предпочитаю case. Даже LambdaCase ;)

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

есть, но там точка еще, проще сделать одну проверку, а не две

is_number = uncurry (and `on` numbers_only) . second tailSafe . span (/= '.') where numbers_only = map (`elem` ['0'..'9'])

да сравнивайте вы уже с >= '0' && c <= '9'

numbers_only, is_number - не надо так!

а вообще на хакадже есть is-number вроде

а вообще на хакадже есть is-number вроде

Докатились

left-pad

для такого уже комбинаторный парсер надо

Перенимаем опыт JS

Докатились

ну так в Acme.