Alexander
лютое и бешенное метапрограммирование на пустом месте
кана
руби с кложей очень похожи
кана
ну и я не сказал бы что в кложе много меты, сахарок для define разный, пайпы
Alexander
и как рубист я могу заметить, что знаю о чем говорю когда называю похожие на руби языки говном
Alexander
мету надо вырывать с корнем а потом крайне тщательно дозировать
Alexander
а не эти истории про объявление функции в рантайме
Alexander
я наверно не совсем точно выразился, имеется в виду не вычисление в случае с какими то замыканиями а именно натуральное объявление
Alexander
не было в неймспейсе функции и вот она
Alexander
кложура в этом плане просто заменяет рантайм на компайл-тайм в котором творится та же дичь
тот
в конечном то итоге нужно роботов делать на языке что сможет обеспечить перенос алгоритмов, споры о языках бесконечны если забыть что программирование = прикладная математика
Aliester
программирование - прикладное страдание
Vladislav
A64m
не анбоксед суммы (их вмерджили), а анпак сумм
Vladislav
А, понял
Vladislav
Ну и бардак
тот
Vladislav
A64m
https://phabricator.haskell.org/D2424
Vladislav
Мне кажется у SPJ между его пейперами, докладами, патчами, и еще дневной работы, времени на сон не остается
Vladislav
И постоянно все ломают ему билды GHC на Windows
Vladislav
Каждый месяц в ghc-dev у него что-то не билдится из-за чьих-то патчей
Vladislav
А потом ему еще на ghc-proposals приходится комментить, и Trac тикеты читать
Vladislav
И с его позицией небось емайлов по 20 в день прилетает.
Vladislav
Короче я не знаю когда он живет вообще, типа там погулять выйти
a66ath
Это не наши
Dmitry
Dmitry
Dmitry
Влод
Alexander
Vladislav
Vladislav
Смотрите чего откопал
Vladislav
> December 17, 2015
> I hope to have a prototype of -XDependentTypes available in 6 months or so
Я ДЖВА ГОДА ЖДУ.
A64m
да, завтипы в 8.0 одно время обещали
Alexander
Так это единичный случай, или он по другим поводам тоже обещает сделать?
Leonid 🦇
Artem
A64m
https://github.com/ghc/ghc/commit/60e4bb4d305bc1a65457ee79b1e69c11b9ed747d
A64m
ну ладно, но за D4766 я больше переживаю
Vladimir
неужели этот бойлерплейт нельзя было по-человечески написать?
Vladimir
какой-нибудь редукцией свести к какой-нибудь форме, ну
Cheese
A64m
смотря какие
A64m
это, наверное, должно несколько улучшать код где в анбоксед/сторабл векторах какие-то сложные структуры вложены и инстансы для анбоксед не написаны как вектор рекордов -> рекорд векторов. т.е. как в Linear
A64m
но эту гипотезу я не проверял
.sυλ
Как к функции типа a -> b -> c -> IO d применять IO-аргументы? >>= работает только с унарными. a, b, и c нужно как-то объединить?
Ilya
do-нотацию знаешь? хотя тут можно и без неё
Ilya
do
a <- ma
b <- mb
c <- mc
f a b c
Ilya
ma, mb, mc — это твои IO-аргументы, f -- функция
.sυλ
А как без do это будет выглядеть?
кана
кана
join :: Monad m => m (m a) -> m a
liftA2
:: Applicative f
=> (a -> b -> c) -> (f a -> f b -> f c)
join . liftA2
:: Monad m
=> (a -> b -> m c) -> (m a -> m b -> m c)
с учетом аргументов композиции, то есть тут . абстрактный
print3 :: String -> String -> String -> IO ()
print3 a b c = print $ a ++ b ++ c
main :: IO ()
main = join $ liftA3 print3 getLine getLine getLine
Ilya
Cheese
через do будет понятнее спрашивающему
кана
ну у него был конкретный вопрос: "как без do?"
Ilya
Аппликативы рулят!
кана
на самом деле я не считаю, что с ду однозначно понятнее, потому что с liftAN код выглядит как просто применение функции, а в do придется выдумывать имена
то есть было f a b, стало liftA2 f a b
Ilya
Но "без-ду-шная" нотация это 5+
Ilya
В одну копилку с pointless
кана
а вот ввели бы bang как выражение
кана
main = f (<- a) (<- b) (<- c)
.sυλ
Кстати, какой лимит N в функциях liftN и подобных? Они автоматически генерируются?
кана
http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Applicative.html
кана
определены до 3
кана
но
liftA3 f a b c = f <$> a <*> b <*> c
кана
liftA4 f a b c d = f <$> a <*> b <*> c <*> d
liftA5 f a b c d e = f <$> a <*> b <*> c <*> d <*> e
кана
то есть они пишутся тривиально и можно вообще без lift
Ilya
@kana_sama зацени
https://stackoverflow.com/questions/49628762/lifting-generalization
кана
A64m
это страшно Ж(((
кана
да нет
A64m
пропозал вообще страшнейший
кана
do дает в "синтаксический скоуп" <-
A64m
по сравнению с идрисным синтаксисом
кана
как "стейтмент", так и выражение
Vladislav
https://github.com/ghc/ghc/commit/8df24474d0194d28b8273c1539af05793156e23f
Предписываю всем -Werror=implicit-kind-vars теперь включать