AP
Скобки бы не мешали, если бы
<&> и & имели сходные с "обратными" вариантами фикситиinfixr 5 <&> был бы норм, наверноеSize: a a a
2021 January 07
AP
Собсно,
AP
> :{
(<.>) = (<&>)
infixr 5 <.>
:}
> 5 & (+ 1) <.> show
"6"JS
у ($) и (&) тоже приоритеты разные, несмотря на логическую симметрию
JS
λ> :i $ &
infixr 0 $
infixl 1 &AP
Выше я это уже отметил
AP
Это различие позволяет смешивать эти два оператора в одном выражении
AP
Но смешивание именно & и <&> работает плохо
AP
(не так, как хотелось бы)
AP
Это различие позволяет смешивать эти два оператора в одном выражении
pure $
a & foo +~ 1удобно, например
JS
а ещё можно "инфиксить" целые выражения:
==
map1 & Data.Map.unionWith (+) $ map2==
Data.Map.unionWith (+) map1 map2AP
(/me ещё любит трюк с инфиксным
flip, просто к слову)MK
(/me ещё любит трюк с инфиксным
flip, просто к слову)Может ты ещё и сечение композиции любишь?
AP
Люблю. Не злоупотребляю
JS
а ещё можно "инфиксить" целые выражения:
==
map1 & Data.Map.unionWith (+) $ map2==
Data.Map.unionWith (+) map1 map2кстати, забавно, что чаще всего я использую бэктики наоборот — для "префиксной" формы:
(`runReaderT` a) $ (`runStateT` b) $ do
...
JS
(/me ещё любит трюк с инфиксным
flip, просто к слову)в lens есть (??), с ним ещё красивее
G
Имелась в виду развернутая композиция
Да, к примеру, есть
contents <- getArgs >>= readFile . head <&> linesно
contents <- getArgs >>= head >>> readFile <&> linesвыглядит читабельнее, т.к. функи в соответствующем порядке слева направо. Но из-за прецедентности >>> придется в скобки брать
JS
(`f` a) == f `flip` a == f ?? a
MK
Отвратительно
JS
Да, к примеру, есть
contents <- getArgs >>= readFile . head <&> linesно
contents <- getArgs >>= head >>> readFile <&> linesвыглядит читабельнее, т.к. функи в соответствующем порядке слева направо. Но из-за прецедентности >>> придется в скобки брать
но <- портит всё