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

Догадываюсь, что при отладке рантайм-ошибок пошаговая отладка будет менять порядок эвалюэйшона и может привести к гейзенбагам

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

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

Упасть может, если посчитать что-то не то

вот так и получится квантовый отладка (когда наблюдение влияет на процесс)

это не квантовая отладка как раз, меняться должен не (только) процесс, а конечный результат

Упасть может, если посчитать что-то не то

если оно всё равно вычисляется в программе, то всё равно упадёт, неважно, когда. а если в программе есть задумка, которая никогда не должна вычисляться, это что-то странное (хотя я такое использовал разок)

а вот в c++ у меня было один раз, что добавление отладочного принта меняет результат работы кода (физические вычисления)

а вот в c++ у меня было один раз, что добавление отладочного принта меняет результат работы кода (физические вычисления)

о, там это регулярно! обычно причиной оказывается мусор в памяти, да?

в тот раз по-моему просто была проблема в Ofast

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

К сожалению, может ? Потому что есть ленивое IO. Такой код не работает в Haskell: readFile file >>= writeFile file Но если полностью зафорсить вычисление результата readFile перед writeFile, то будет работать безупречно.

Т.е. порядок монадических эффектов не гарантируется?

К сожалению, может ? Потому что есть ленивое IO. Такой код не работает в Haskell: readFile file >>= writeFile file Но если полностью зафорсить вычисление результата readFile перед writeFile, то будет работать безупречно.

действительно, если есть unsafePerformIO (ленивое IO, "иностранные" библиотеки и прочите небезопасные трюки)

Т.е. порядок монадических эффектов не гарантируется?

монадических — гарантируется, а всё, что касается unsafe, не гарантируется

Стандартные IO эффекты unsafe?

Стандартные IO эффекты unsafe?

нет, только с lazy IO проблемы

Есть еще волшебный error

Есть еще волшебный error

fix error

Есть еще волшебный error

что в нём волшебного?

>>> Такой код не работает в Haskell: readFile file >>= writeFile fileПочему?

>>> Такой код не работает в Haskell: readFile file >>= writeFile fileПочему?

эффект readFile — не прочитать весь файл, а открыть файл и читать по требованию

что в нём волшебного?

он не в монаде

он не в монаде

скорее, наоборот, меньше монад — меньше магии

скорее, наоборот, меньше монад — меньше магии

звучит как unsafePerformIO

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

звучит как unsafePerformIO

там внутри нет такого

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

это нормально для любого ленивого вычисления

это нормально для любого ленивого вычисления

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

вот кстати не помогло! очень интересно stm и async не профилируются типа

как обычно я ступил - сделал cabal init вместо cabal sandbox init

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

такое в реальных программах случается?

такое в реальных программах случается?

а есть принципиальная разница?

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

если у тебя bottom в каких-то случаях, то либо программа недописана, либо тебе именно это и нужно

а есть принципиальная разница?

да, это либо полезно, либо невозможно

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

нет, ленивый порядок вычисления — это один порядок

да, это либо полезно, либо невозможно

определять "невозможно" состоянием на текущий момент времени странно

сам принцип ленивого выисления ни от чего не зависит. в конкретные запусках вычисленность задумок зависит только от того, были ли они запрошены

демамогию разводишь ведь

сам принцип ленивого выисления ни от чего не зависит. в конкретные запусках вычисленность задумок зависит только от того, были ли они запрошены

(если нет unsafe)

демамогию разводишь ведь

нет, ты начал со странных тезисов, я пытаюсь вытащить из тебя обоснование

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

что вот это значит?

что вот это значит?

значит что вернется либо значение либо bottom

значит что вернется либо значение либо bottom

докажи, что это зависит от порядка вычисления в Хаскелле

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

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

нет

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

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

Ну то есть правила по которым опрелеяется что и в каком порядке будет вычислено фиксированны, но если менять программу, то изменения порядка вычислений могут быть весьма дальнодействующими

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

шагать локально, и не будет особых выпрыгиваний непонятно куда

я в курсе, что гхци отладчик принято ненавидеть, но это полезная фича для недоразработки в недорепле

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

ну да, только переписать программу или ключик -XStrict в ghc передать

я в курсе, что гхци отладчик принято ненавидеть, но это полезная фича для недоразработки в недорепле

ghci недорепл?

да

интересно почему

и где тогда нормальный репл

ни где

в скриптах вроде лиспа, но такое суповое программирование не для хаскеля, конечно

конечно, есть фичи которые и в хаскельном репле не помешали бы, но в гхци их нет

там внутри нет такого

unsafeInterlealveIO там

unsafeInterlealveIO там

в error?

а в readFile

я неверно значит тред распарсил

до 17 стек можно было для начинающих смело рекомендовать, хотя нью кабал уже был получше. но последнее время там какое-то адище с хпаком, постоянно ошибки, отставание от гхц (даже 8.2 еще поддерживается не полностью), проблемы на виндовс и т.д.

Ну, у ghc проблемы на виновс x86 с 8.2, но что-то это никого не волнует

да x86 гхц все равно ничего не соберет

ERROR: S client not available

просто памяти не хватит

Хорошо, что у разрабов ghc нет такого стремления избежать успеха, и вроде 8.6 будет работать на x86

продолжит ничего не собирать

Зачем нужна поддержка x86? Вы бы ещё pdp-11 просили

Попосту теряют время разработчиков

на виндовс ещё

Мне вот нужна, хотя бы в рабочее время

Мне вот нужна, хотя бы в рабочее время

Это не ответ на вопрос зачем

Это не ответ на вопрос зачем

Развлекаться в рабочее время, зачем еще нужен хаскель?

У вас на работе 32'битная ОС?

?

А вот по поводу "теряют время": 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

32 битная виндовс виста рутракер голд эдишн. Жаль, разработчики гхц не учли

У вас на работе 32'битная ОС?

Вот только без кибербуллинга?

Какой уж тут буллинг, тут сочувствовать надо

Могу посоветовать только виртуалку купить

@romastyi будет жить. Поприветствуем!

@Dankkkk будет жить. Поприветствуем!

не прошло и 100 лет https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

Так, глядишь, к 2048-му и получим Java 2.0

не прошло и 100 лет https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

Драфт, кстати странный. Представим, что я хочу потребовать (N, E Graph) и (N Equal). Совершенно непонятно, как это сделать в таком синтаксисе

А когда дженерики появились? @A64m_qb0 , может, подскажешь?

В 72 Жирар придумал System F

А когда дженерики появились? @A64m_qb0 , может, подскажешь?

Java 2004 https://en.wikipedia.org/wiki/Generics_in_Java ML 1973? https://en.wikipedia.org/wiki/Generic_programming

Вроде, в конце 70-ых? В Ada

кстати, а есть реализации System F за пределами семейства ML?

в актуальных языках, разумеется. Не обязательно статической

Parametric polymorphism was first introduced to programming languages in ML in 1975_

кстати, а есть реализации System F за пределами семейства ML?

Возможно а64м быстренько объяснит тебе сейчас, что хашкел - это не МЛ

Лучше не надо я и так верю что он может