6 ms·
If you disable lazy evaluation, you would not be able to write arbitrary "where" sections, with definitions ordered as you want them, including tying-the-knot d
by thesz 4y ago
If you disable lazy evaluation, you would not be able to write arbitrary "where" sections, with definitions ordered as you want them, including tying-the-knot definitions, which are not exceptionally rare.
So no one disables lazy evaluation.
It is strict evaluation that is selectively enabled.
I also have to say that focusing on the types in the compiler development was the right thing, but what was not right is not focusing on the automatic analysis and removal of thunk creation for lazy evaluation. There is a project now to implement GRIN (graph reductin intermediate notation) [1] which supports such analysis and GRIN is early 90-th.
[1] https://grin-compiler.github.io/ https://grin-compiler.github.io/
GRIN also automatically gives you many benefits of supercompilation.
We could have a much better Haskell code now if ghc decided to support several backends back then, not only STG/C--.
- kerkeslager 4y ago> So no one disables lazy evaluation. That's objectively incorrect.
- deleted 4y ago[deleted]
- scns 4y ago> It is strict evaluation that is selectively enabled. Worth fighting over it? Zero snark intended.
- kerkeslager 3y agoProbably not!
- foldr 3y ago>So no one disables lazy evaluation. It is strict evaluation that is selectively enabled. True of vanilla Haskell, but from the article: > So we ended up with Mu, a whole-program compiler to a bytecode representation with a small runtime interpreter... Mu has a strict runtime, which makes program performance easier to analyse and predict – but prevents us from just copy-pasting some Haskell libraries that rely crucially on lazy evaluation. If S&C is to count as a Haskell success story (which it's often touted as), then I think it's fair to point out that it's a codebase where strict evaluation is used throughout.
- thesz 3y agoMu was developed using Haskell, that's the point. The strict runtime and interpreter may or may not be build using Haskell, I dont't know. As far as I know, the author of Mu is Lennart Augustsson, also author of Bluespec [1]. Bluespec compiles language that is very reminiscent of Haskell into a hardware gates. And Bluespec is relatively successful. Is there anything in the hardware gates' "evaluation model" that is related to the success of Bluespec.
- foldr 3y agoI mean it's a point, but it's not really the point that the article is making: >In this article of our Haskell in Production series, we interview José Pedro Magalhães from Standard Chartered – a multinational bank that has over 6 million lines of code written in their own dialect of Haskell called Mu.
- tome 3y agoMu is strict because it was designed to target an existing strict runtime. That's all.
- foldr 3y agoQuite possibly, but I suspect there are good reasons why the existing runtime is strict. In any case, regardless of the underlying motivation, it is certainly an interesting fact that one of the largest commercial Haskell(ish) codebases uses a strict variant of the language.
- thesz 3y agoMu is not Haskell, it is entirely different language. The Haskell codebase that made Mu possible is not strict.
- foldr 3y ago> their own dialect of Haskell called Mu. [emphasis mine] >Mu has a strict runtime, which makes program performance easier to analyse and predict – but prevents us from just copy-pasting some Haskell libraries that rely crucially on lazy evaluation. [emphasis mine] If Mu were an entirely different language then you wouldn't be able to copy-paste any Haskell libraries. See also e.g. here: https://www.quora.com/Why-did-Standard-Chartered-need-its-own-Haskell-compiler https://www.quora.com/Why-did-Standard-Chartered-need-its-ow..., https://www.youtube.com/watch?v=hgOzYZDrXL0 https://www.youtube.com/watch?v=hgOzYZDrXL0