3 ms·

>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

by foldr 4y 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 4y ago
Mu 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 4y ago
  I 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 4y ago
Mu is strict because it was designed to target an existing strict runtime. That's all.
- foldr 4y ago
  Quite 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 4y ago
    Mu is not Haskell, it is entirely different language. The Haskell codebase that made Mu possible is not strict.
    - foldr 4y 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
      - thesz 4y ago
        I can copy-paste some of Haskell definitions into Agda source file and vice versa. I can copy-paste some of C code into C++ source and vice versa. Given C preprocessor, some Lisp code can be moved into C or other languages. The likeness of languages' syntaxes does not mean they are the same.
        foldr 4y ago
        https://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf https://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Mu is a true Haskell dialect in that code written in Mu may be compiled with a Haskell compiler. > [...] > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, […] My point was that "if S&C is to count as a Haskell success story (which it's often touted as), then it's fair to point out that it's a codebase where eager evaluation is used throughout." Please note the 'if'. The article presents S&C's large Mu codebase as a Haskell success story. In this context it's perfectly fair to point out that Mu has a strict semantics. If you want to insist that Mu is an 'entirely different' language to Haskell then that's fine. As with natural languages, there's no objective line to be drawn between 'different dialect' and 'different language'. However, anyone who holds to this view obviously cannot follow the article in presenting a large Mu codebase as an example of Haskell in production.
- ParetoOptimal 4y ago
  > Quite possibly, but I suspect there are good reasons why the existing runtime is strict. This makes me wonder if this affects how code is typically written. Is it very elm like? Is composition more difficult? Is it very monomorphic?

by foldr 4y ago

thesz 4y ago

Mu 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 4y ago
I 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 4y ago

Mu is strict because it was designed to target an existing strict runtime. That's all.

foldr 4y ago
Quite 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 4y ago
  Mu is not Haskell, it is entirely different language. The Haskell codebase that made Mu possible is not strict.
  - foldr 4y 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
    - thesz 4y ago
      I can copy-paste some of Haskell definitions into Agda source file and vice versa. I can copy-paste some of C code into C++ source and vice versa. Given C preprocessor, some Lisp code can be moved into C or other languages. The likeness of languages' syntaxes does not mean they are the same.
      - foldr 4y ago
        https://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf https://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Mu is a true Haskell dialect in that code written in Mu may be compiled with a Haskell compiler. > [...] > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, […] My point was that "if S&C is to count as a Haskell success story (which it's often touted as), then it's fair to point out that it's a codebase where eager evaluation is used throughout." Please note the 'if'. The article presents S&C's large Mu codebase as a Haskell success story. In this context it's perfectly fair to point out that Mu has a strict semantics. If you want to insist that Mu is an 'entirely different' language to Haskell then that's fine. As with natural languages, there's no objective line to be drawn between 'different dialect' and 'different language'. However, anyone who holds to this view obviously cannot follow the article in presenting a large Mu codebase as an example of Haskell in production.
ParetoOptimal 4y ago
> Quite possibly, but I suspect there are good reasons why the existing runtime is strict. This makes me wonder if this affects how code is typically written. Is it very elm like? Is composition more difficult? Is it very monomorphic?