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

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

Всё правильно делают

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

Ему не того, ему тенюру получать надо… (постоянную позицию в универе)

https://github.com/ghc/ghc/commit/60e4bb4d305bc1a65457ee79b1e69c11b9ed747d

ну ладно, но за D4766 я больше переживаю

неужели этот бойлерплейт нельзя было по-человечески написать?

какой-нибудь редукцией свести к какой-нибудь форме, ну

https://github.com/ghc/ghc/commit/60e4bb4d305bc1a65457ee79b1e69c11b9ed747d

теперь константы будут вычисляться совершенно бесплатно?

смотря какие

это, наверное, должно несколько улучшать код где в анбоксед/сторабл векторах какие-то сложные структуры вложены и инстансы для анбоксед не написаны как вектор рекордов -> рекорд векторов. т.е. как в Linear

но эту гипотезу я не проверял

Как к функции типа a -> b -> c -> IO d применять IO-аргументы? >>= работает только с унарными. a, b, и c нужно как-то объединить?

do-нотацию знаешь? хотя тут можно и без неё

do a <- ma b <- mb c <- mc f a b c

ma, mb, mc — это твои IO-аргументы, f -- функция

А как без do это будет выглядеть?

Как к функции типа a -> b -> c -> IO d применять IO-аргументы? >>= работает только с унарными. a, b, и c нужно как-то объединить?

join . liftAN

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

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

У него liftA3 только

через do будет понятнее спрашивающему

ну у него был конкретный вопрос: "как без do?"

ну у него был конкретный вопрос: "как без do?"

это @Masteroid упомянул без-ду-шную нотацию, я считаю, зря

Аппликативы рулят!

на самом деле я не считаю, что с ду однозначно понятнее, потому что с liftAN код выглядит как просто применение функции, а в do придется выдумывать имена то есть было f a b, стало liftA2 f a b

Но "без-ду-шная" нотация это 5+

В одну копилку с pointless

а вот ввели бы bang как выражение

main = f (<- a) (<- b) (<- c)

Кстати, какой лимит 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

main = f (<- a) (<- b) (<- c)

вроде в той версии что обсуждалась надо do писать т.е ``` main = do f (<- a) (<- b) (<- c) ```

то есть они пишутся тривиально и можно вообще без lift

@kana_sama зацени https://stackoverflow.com/questions/49628762/lifting-generalization

вроде в той версии что обсуждалась надо do писать т.е ``` main = do f (<- a) (<- b) (<- c) ```

ну это не страшно и вполне логично, я просто забыл

это страшно Ж(((

да нет

пропозал вообще страшнейший

do дает в "синтаксический скоуп" <-

по сравнению с идрисным синтаксисом

как "стейтмент", так и выражение

https://github.com/ghc/ghc/commit/8df24474d0194d28b8273c1539af05793156e23f Предписываю всем -Werror=implicit-kind-vars теперь включать

Через 2 релиза все равно сломаю

Т.е. если не включить сейчас, то через 2 релиза код сломается.

@kana_sama зацени https://stackoverflow.com/questions/49628762/lifting-generalization

ага, писал такое тоже, но пользовать таким нереально, ошибкие тоже непонятные, выводится иногда не то и тд

Всегда можно сделать n+1 имея liftN liftN+1 = (<*>) + liftN

вроде в той версии что обсуждалась надо do писать т.е ``` main = do f (<- a) (<- b) (<- c) ```

Красиво, но не работает. Parse error

Красиво, но не работает. Parse error

это только пропозал

(причем заброшенный уже, вроде)

[большая горечь]

To do this, we formalize the notion of kind, writing * for the kind of all types and k1 -> k2 for the kind of a constructor which takes something of kind k1 and returns something of kind k2. This notion comes is motivated by some theoretical work by Henk Barendregt on the subject of `Generalized type systems'; Do not confuse this with the use of the symbol * in a certain well-known functional language where it represents a type variable. These things are completely different!

А как должна выглядеть аналогичная, которая получает из него данные?

game ^. boss . health

емнип use (boss.health)

game ^. boss . health

это же стейт

health' <- use $ boss . health можно сразу и менять, и получать: health' <- boss.health <-= 10 как заметил @astynax, можно через gets health' <- gets $ view $ boss.health собственно use = gets . view

В чем разница между runStateT и execStateT? Последний не пропускает эффекты IO?

run отдает и стейт, и результат вычисления в монаде exec отдает только стейт в монаде (когда результат вычисления не важен)

это почти ко всем основным mtl-монадам относится

ERROR: S client not available

у своих я тоже такого нейминга придерживаюсь

есть еще evalStateT, который отдает только результат

run отдает и стейт, и результат вычисления в монаде exec отдает только стейт в монаде (когда результат вычисления не важен)

Функции IO () работать в exec не будут? Почему-то у меня они все глохнут при вызове execStateT

будут, покажи код

будут конечно работать

program :: StateT Int IO () program = do liftIO . putStr $ "inner state: " liftIO . print =<< get modify (+ 10) main :: IO () main = do state <- execStateT program 20 print $ "result state: " ++ state вывод: inner state: 20 result state: 30

В чем разница между runStateT и execStateT? Последний не пропускает эффекты IO?

Может, resultStateT voidStateT были бы понятнее?

а http://hackage.haskell.org/package/gtk норм или есть что то более актуальное?

Может, resultStateT voidStateT были бы понятнее?

run/exec/eval - глаголы. result и void - не то глаголы, не то странные существительные :)

а http://hackage.haskell.org/package/gtk норм или есть что то более актуальное?

gtk3, вероятно

run/exec/eval - глаголы. result и void - не то глаголы, не то странные существительные :)

Разве лингвистика важнее значения/смысла? Конечно, run, exec уже в либе. Да и документацию поднять нетрудно.

Ну имхо от voidState интуиции не больше, чем от execState

Разве лингвистика важнее значения/смысла? Конечно, run, exec уже в либе. Да и документацию поднять нетрудно.

run у всех монадок. Вот exec/eval можно было назвать иначе. Но логика есть и в текущем именовании - exec делается ради эффекта, а eval ради вычисления значения

А я всегда путаю eval / exec ?

у eval должен быть результат, очевидно

так что перепутать сложно

вообще же eval и exec, наверное, от того, что mtl происходит из пейпера про модульные интерпретаторы

> Но логика есть и в текущем именовании - exec делается ради эффекта, а eval ради вычисления значения Вот это, пожалуй, поможет мне запомнить, кто из них a, а кто s

страуструп оправдывался совместимостью с си (не сработало). а чем оправдываются в расте за :: например?

А что не так с ::?

да, и * и бокс из пейпера Барендрегта взял и применил (когда изобретал конструктор классы) Марк Джонс - автор хаскельных фич 90 которые так ненавидят любить и любят ненавидить хаскелисты

можно считать что все виновные установлены, Тернер и Милнер не при чем

бокс, кстати, не имеет отношение ко всяким боксед-лифтед, это просто квадратик из Барендрегтовского пейпера словом

раньше было 0 :: Int :: * :: BOX терм тип кайнд сорт теперь 0 :: Int :: Type :: Type :: Type :: Type терм и типы ол зе вей даун

А почему не стали делать, как в Idris — Type : Type 1 : Type 2: ...? А то меня самовложенность универсума напрягает

> Why do this? One alternative is to go the route of Coq and Agda and have an infinite tower of type universes. But, this adds a lot of complexity. These languages take this route because * :: * makes a language inconsistent as a logic. However, Haskell is already inconsistent as a logic (because of undefined and GHC.Exts.Any) and so we don't have to worry about a new source of inconsistency. Furthermore, the type safety of Haskell does not depend on its own consistency -- unlike Coq and Agda, Haskell relies on the consistency of a coercion language, which is not threatened by * :: *

ух ты, ещё вот так можно λ> instance Num () where fromInteger _ = () λ> 2 == 3 True

Не плоди сиротских инстансов, бессердечный!

Это всё очень сложные вопросы. Можно вопрос поглупее и попроще? Какими значениями населён в этих-ваших идрисах и агдах тип 7? Или 5? Или 92?

Не плоди сиротских инстансов, бессердечный!

это грязный хак. очень грязный

> Why do this? One alternative is to go the route of Coq and Agda and have an infinite tower of type universes. But, this adds a lot of complexity. These languages take this route because * :: * makes a language inconsistent as a logic. However, Haskell is already inconsistent as a logic (because of undefined and GHC.Exts.Any) and so we don't have to worry about a new source of inconsistency. Furthermore, the type safety of Haskell does not depend on its own consistency -- unlike Coq and Agda, Haskell relies on the consistency of a coercion language, which is not threatened by * :: *

tl;dr: В Haskell всё хреново, так что если мы сделаем вложенные универсумы, то хуже не станет. Ну такая себе логика

рано читать перестали > the type safety of Haskell does not depend on its own consistency -- unlike Coq and Agda, Haskell relies on the consistency of a coercion language, which is not threatened by * :: *

короче, вложенными универсумами в хаскеле по памяти не проедешь

меня печалит gtk