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

точно так же как 1 -- перегруженный числовой литерал, который может быть приведен к любому типу с инстансом Num, 1.5 -- это перегруженный дробный (`Fractional`) литерал, который, в свою очередь может быть приведен к любому типа, реализующему Fractional

{-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE StandaloneDeriving #-} import Data.Monoid deriving instance Fractional a => Fractional (Sum a)

> 1.5 :: Sum Float Sum {getSum = 1.5}

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

из-за округления моноидные законы могут не выполняться

Они выполняются приближённо

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

там же Num a => Monoid (Sum a)

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

то есть 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'])

а разве у 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 не общий