Thank you for all the answers.
Simen kjaeraas: >This has to do with D iteration being more designed towards mimicking C >arrays.< I am not able to see the link between the two things. >In D2, you'd use a range, and possibly have popFront return the new (changed) >range.< In D2 both opApply and Range protocol can be used because they are fit for different purposes. In several situations keeping the state manually (As the Range protocol requires) requires more complex code compared to opApply. > (x for x in xrange(2,N) if all(x % i for i in xrange(2,x))) >Except that it also changes the input. The input there is N, and it doesn't get changed. You can see a pure generator like a pure function that returns an array of items. The main difference is that the items of such array are computed & given lazily. >It seems to me the python example uses a closure,< In practice Python uses closures all the time :-) Somewhere that Python generator has to keep memory (state) of where the variable 'i' is. >This closure must then change its associated state upon iteration.< It has a state it changes, but outside the generator the existance of such state can be ignored. The whole point of my post is the idea of something purish, the output of that generator is determined only by the input (N), it generates its results only once and then it stops. >Here's an implementation that seems to work:< The code worth traslating in D2 was the Haskell Fibonacci generator. Thank you for your code, but it's too much noisy, in normal situations I am not willing to write similar code. ------------------------ Jason House: >pure is a keyword in D2 that means something different than how you're using >it.< D2 compiler contains the idea of "pure function" and "pure method", while I am talking about "pure generator", an idea that is not present natively in the D2 compiler. >I'm also fairly ignorant about what is in std.algorithm, but you should be >able to find things that look more like your functional code examples.< You are probably right here, but this is beside the main point of my post. ------------------------ Pelle: >It is stored as a list, and is in effect memoized.< In practice I think Haskell doesn't memoize things there. I think it optimizes most things away. The main point of pure generators is indeed that they give the compiler enough guarantees (just as pure functions) that allow it to perform those optimizations safely. The point of my original post is that I'd like a way to give the D compiler such semantic information, mostly for optimization purposes (but there are other purposes, similarly to the purposes of pure functions). >You can, naturally, create the same in D. It will be more verbose, though. >[...] That should be about the same. :)< Beside being not a pure generator (a semantics that currently can't be expressed to the D2 compiler), your code has very little to do with the way Haskell compiles that program. I can be wrong because I am don't know much about the Haskell compiler(s). Bye, bearophile
