3 ms·
> What would we exactly lose? We'd lose composability and clearer code. This[1] section of the Haskell Wiki contains a good example. In short, with something
by runeks 9y ago
> What would we exactly lose?
We'd lose composability and clearer code. This[1] section of the Haskell Wiki contains a good example.
In short, with something like this:
any :: (a -> Bool) -> [a] -> Bool
any f lst = or boolLst
where boolLst = map f lst
the compiler can produce reasonably optimal code, because it doesn't have to convert the entire [a] to a [Bool], because of lazy evaluation -- when or encounters the first True, the map f lst expression stops being evaluated because of lazy evaluation.
[1] https://wiki.haskell.org/Non-strict_semantics#Why.3F https://wiki.haskell.org/Non-strict_semantics#Why.3F
- vesak 9y agoI don't know Idris so this syntax is probably wrong, but by reading the docs for a short while, this would be any : (a -> Bool) -> Lazy List a -> Bool ... which would make it as performant and clearer than Haskell's any, since the laziness is explicit. Someone with actual Idris experience might tell if it actually would work like this :) I guess we'd have to make sure that the used or function is also lazy.
- runeks 9y agoI was commenting on what the effects would be from removing laziness. I'm not experienced enough in Haskell to know whether making strictness the default option would make sense, although I've seen a quote from Simon Peyton Jones saying he'd do that if he could start over. Out of curiosity, would you know whether there exists sufficient strictness pragmas in Haskell to translate your example Idris (pseudo) code into Haskell? I often hear about performance/memory usage pitfalls with Haskell laziness, so it'd be really nice if Haskell were able to emulate Idris in this regards, by enabling enough LANGUAGE pragmas to require explicitly annotating types if laziness is desired.