Proposed new syntax

[Ian Kelly]

On Mon, Aug 14, 2017 at 8:24 PM, Steve D'Aprano
<steve+python at 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.