Ilya
а вот в c++ у меня было один раз, что добавление отладочного принта меняет результат работы кода (физические вычисления)
Cheese
а вот в c++ у меня было один раз, что добавление отладочного принта меняет результат работы кода (физические вычисления)
о, там это регулярно! обычно причиной оказывается мусор в памяти, да?
Ilya
в тот раз по-моему просто была проблема в Ofast
Dmitrii
хотя от изменения порядка вычисления не должно ничего меняться, кроме потребления памяти
К сожалению, может 😞 Потому что есть ленивое IO. Такой код не работает в Haskell:
readFile file >>= writeFile file
Но если полностью зафорсить вычисление результата readFile перед writeFile, то будет работать безупречно.
Mi Shа
Т.е. порядок монадических эффектов не гарантируется?
Cheese
К сожалению, может 😞 Потому что есть ленивое IO. Такой код не работает в Haskell:
readFile file >>= writeFile file
Но если полностью зафорсить вычисление результата readFile перед writeFile, то будет работать безупречно.
действительно, если есть unsafePerformIO (ленивое IO, "иностранные" библиотеки и прочите небезопасные трюки)
Cheese
Т.е. порядок монадических эффектов не гарантируется?
монадических — гарантируется, а всё, что касается unsafe, не гарантируется
Mi Shа
Стандартные IO эффекты unsafe?
Alexander
Есть еще волшебный error
Mi Shа
>>> Такой код не работает в Haskell:
readFile file >>= writeFile fileПочему?
Cheese
>>> Такой код не работает в Haskell:
readFile file >>= writeFile fileПочему?
эффект readFile — не прочитать весь файл, а открыть файл и читать по требованию
Alexander
суть в том что в зависимости от порядка вычислений он может либо вычислится либо нет
Cheese
суть в том что в зависимости от порядка вычислений он может либо вычислится либо нет
это нормально для любого ленивого вычисления
Alexander
это нормально для любого ленивого вычисления
да, но не очень хорошо когда в зависимости от порядка вычисления у тебя либо bottom либо нет
Misha
вот кстати не помогло! очень интересно
stm и async не профилируются типа
как обычно я ступил - сделал cabal init вместо cabal sandbox init
Cheese
да, но не очень хорошо когда в зависимости от порядка вычисления у тебя либо bottom либо нет
такое в реальных программах случается?
Cheese
да, но не очень хорошо когда в зависимости от порядка вычисления у тебя либо bottom либо нет
если у тебя bottom в каких-то случаях, то либо программа недописана, либо тебе именно это и нужно
Alexander
если у тебя в ленивом языке что то зависит от порядка вычисления то ты делаешь что то не то, аксиома же
Cheese
нет, ленивый порядок вычисления — это один порядок
Alexander
да, это либо полезно, либо невозможно
определять "невозможно" состоянием на текущий момент времени странно
Cheese
сам принцип ленивого выисления ни от чего не зависит. в конкретные запусках вычисленность задумок зависит только от того, были ли они запрошены
Alexander
демамогию разводишь ведь
Cheese
Cheese
демамогию разводишь ведь
нет, ты начал со странных тезисов, я пытаюсь вытащить из тебя обоснование
Cheese
Cheese
значит что вернется либо значение либо bottom
докажи, что это зависит от порядка вычисления в Хаскелле
Ilya
а что в хаскеле порядок вычислений можно менять?
Алексей
Ну то есть правила по которым опрелеяется что и в каком порядке будет вычислено фиксированны, но если менять программу, то изменения порядка вычислений могут быть весьма дальнодействующими
A64m
скорее, пошаговое выполнение будет выглядеть как хаотическое
шагать локально, и не будет особых выпрыгиваний непонятно куда
A64m
я в курсе, что гхци отладчик принято ненавидеть, но это полезная фича для недоразработки в недорепле
Ilya
если не переписывать программу, нельзя
ну да, только переписать программу или ключик -XStrict в ghc передать
Ilya
A64m
да
Ilya
интересно почему
Ilya
и где тогда нормальный репл
Oleg
ни
где
A64m
в скриптах вроде лиспа, но такое суповое программирование не для хаскеля, конечно
A64m
конечно, есть фичи которые и в хаскельном репле не помешали бы, но в гхци их нет
Alexander
а в readFile
Alexander
я неверно значит тред распарсил
undefined
до 17 стек можно было для начинающих смело рекомендовать, хотя нью кабал уже был получше. но последнее время там какое-то адище с хпаком, постоянно ошибки, отставание от гхц (даже 8.2 еще поддерживается не полностью), проблемы на виндовс и т.д.
Ну, у ghc проблемы на виновс x86 с 8.2, но что-то это никого не волнует
A64m
да x86 гхц все равно ничего не соберет
A64m
просто памяти не хватит
undefined
Хорошо, что у разрабов ghc нет такого стремления избежать успеха, и вроде 8.6 будет работать на x86
A64m
продолжит ничего не собирать
Евгений
Зачем нужна поддержка x86? Вы бы ещё pdp-11 просили
Евгений
Попосту теряют время разработчиков
Oleg
на виндовс ещё
undefined
Мне вот нужна, хотя бы в рабочее время
Евгений
У вас на работе 32'битная ОС?
Евгений
😮
undefined
А вот по поводу "теряют время":
It allocates nearly 18KB of spill slots for a simple 4 line function
and doesn't even use it. Note that this doesn't happen on x64 or
when making a validate build. Only when making a build without a
validate and build.mk.
Цитата отсюда - https://ghc.haskell.org/trac/ghc/ticket/15154
Oleg
32 битная виндовс виста рутракер голд эдишн. Жаль, разработчики гхц не учли
Евгений
Какой уж тут буллинг, тут сочувствовать надо
Евгений
Могу посоветовать только виртуалку купить
Anonymous
@romastyi будет жить. Поприветствуем!
Anonymous
@Dankkkk будет жить. Поприветствуем!
Зигохистоморфный
не прошло и 100 лет
https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
Dmitry
Так, глядишь, к 2048-му и получим Java 2.0
Oleg
не прошло и 100 лет
https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
Драфт, кстати странный.
Представим, что я хочу потребовать (N, E Graph) и (N Equal).
Совершенно непонятно, как это сделать в таком синтаксисе
Dmitry
А когда дженерики появились? @A64m_qb0 , может, подскажешь?
Oleg
В 72 Жирар придумал System F
Anonymous
А когда дженерики появились? @A64m_qb0 , может, подскажешь?
Java 2004
https://en.wikipedia.org/wiki/Generics_in_Java
ML 1973?
https://en.wikipedia.org/wiki/Generic_programming