On Mon, Aug 14, 2017 at 8:24 PM, Steve D'Aprano <steve+pyt...@pearwood.info> wrote: > I think the closest analogy in Python terms would be a generator expression > with > a cache. That's not *quite* the same, because Python is eagerly evaluated and > Haskell is lazily evaluated, but the critical fact (which Ian seems to have > completely missed) is that while evaluation can be delayed, touching each > element *in order* from start to end cannot be. You cannot jump to an > arbitrary > index in Haskell. > > But one thing is sure: even if evaluation is delayed, before you can access > element N, you have to access element N-1. Whether it is implemented via > recursion, a while-loop, or an actual for-loop, it is still logically > equivalent to a for-loop through the elements.
I don't think that I've missed anything here. That the *implementation* uses some kind of recursive application does not make the *semantics* of the list comprehension logically equivalent to a for loop. This is about as close as you can get to a for loop with side effects in Haskell: Prelude Data.Traversable> forM [1..5] $ \n -> print $ n*n 1 4 9 16 25 [(),(),(),(),()] And here's taking the last element of a list comprehension that, according to you, should be "logically equivalent" to the above loop: Prelude Data.Traversable> [ print $ n*n | n <- [1..5] ] !! 4 25 Wait, where are the side effects of the first four elements that had to be recursed over to get to the last element? Clearly these are not logically equivalent. As I said, Haskell list comprehensions are not loops. -- https://mail.python.org/mailman/listinfo/python-list
