6 ms·
For one Lisp is not lazy like Haskell.
by layoutIfNeeded 6y ago
For one Lisp is not lazy like Haskell.
- ssivark 6y agoI don’t understand why the above got down-voted... Without fusing (lazy) loops, having a bunch of independent sequential transformations (each with its own loop) can make the same computation significantly slower!
- vc8f6vVV 6y agoRuby or Scala don't have lazy evaluation by default, yet there are views (Scala) or lazy (Ruby), so no, you don't necessary need compiler help.
- layoutIfNeeded 6y agoYeah, you can emulate laziness at the library level with iterators, coroutines and whatnot, but it always comes with a certain API friction (some readers might be familiar with the “colored functions” analogy [1]) compared to Haskell’s approach that takes laziness to the extreme. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
- anchpop 6y agoI was really hoping that article was going to start talking about effect systems. They're so cool! They make it possible to have many different function colors without it being a huge chore. They can be thought of as a more-ergonomic generalization of monads.
- kjeetgill 6y agoNot super familiar either language, how does lazy evaluation promote the use of smaller functions?
- jokethrowaway 6y agoIn non-lazy languages you would need to implement laziness to manage composing functions and have good performance. An example being take 5 . filter ... If evaluation wasn't lazy you would run take 5, return the result to filter and so on.
- vc8f6vVV 6y agoIn the languages I use (Scala, Ruby) it's already done, Rust is using iterators which are lazy too. None of those languages are "lazy" in Haskell sense.
- layoutIfNeeded 6y agohttps://news.ycombinator.com/item?id=24031945 https://news.ycombinator.com/item?id=24031945
- howling 6y agoThe article elaborates on this point a bit: > Like pipes in UNIX, the functions are clever enough to be performant when composed together–we don’t traverse the whole list and generate a new list each time, each item is generated on demand. In fact, due to stream fusion, the code will be compiled into one fast loop. I imagine it is hard to do the same optimization in a non-lazy language.
- klipt 6y agoIt's interesting that he says you also need purity to do the optimization, but Unix pipes are not necessarily pure.
- garethjrowlands 6y agoUnix pipes don't do stream fusion, which is the optimisation to which he was referring.
- klipt 6y agoSo if I put (x1, x2...) through pipes f and g, instead of calculating all the f(x)s first followed by all the g(f(x))s, it calculates g(f(x1)), then g(f(x2)), etc. How is that order of operations different to stream fusion? Why does stream fusion require more purity than Unix pipes?
- newen 6y agoLet's say there's a global mutable variable M (doesn't have to global, can be x1.M = M, x2.M = M, for example, but easier to think with global) which is used by and modified when f(x) or g(y) runs. Then, the order of operations would matter and so you get different results with and without stream fusion.
- klipt 6y agoRight, but couldn't the same thing happen with Unix pipes if the components write to a global file? You can do the same optimization Unix pipes does without language enforced purity, just with a caveat that functions sharing state might behave weirdly when fused.
- atroche 6y agoI'm sure you (OP) are aware, but just in case others aren't: Clojure stands out as a Lisp that embraces laziness.