3 ms·
&& is always strict in its first argument. Pattern matching is strict. It's hard to predict when some random function you call with force a thunk you've passed
by quotemstr 6y ago
&& is always strict in its first argument. Pattern matching is strict. It's hard to predict when some random function you call with force a thunk you've passed it. My position is still that lazy-by-default is a really bad evaluation policy and that consequently, Haskell is a dead end in language evolution.
- pyrale 6y ago> && is always strict in its first argument. Well, if you need to evaluate (&&) you will necessarily need to evaluate its first argument. Much like (||). This behaviour works similar in many other languages. On the other hand, the first argument passed to (&&) will never be evaluated until needed, so it is still lazy as expected. A good way to test this behaviour is to try this in GHCI: let a = (length [1..] == 3) && False Simply declaring a won't enter in an endless loop, but asking to show a will indeed loop endlessly. Likewise, it is hard to understand how you expect pattern matching to not look at an expression's value when deciding which branch of the code it should use next. > My position is still that lazy-by-default is a really bad evaluation policy and that consequently, Haskell is a dead end in language evolution. Yeah, I have understood that you have an opinion. Nevermind that people run it in production without issues.
- quotemstr 6y agoPeople run Java in production without issues, but we know today that languages shouldn't have nullable-by-default pointers. Software is infinitely malleable: that you can make something work is no argument that it's the right thing.
- pyrale 6y agoPeople rarely call Java a dead end, or irreparably broken, though.