Wouldn't it be better to make Generator >> #do: not use #atEnd?
With the new implementation the following happens:

| generator |
generator := Generator on: [ :g | ].
generator atEnd
"==> false"

| generator |
generator := Generator on: [ :g | ].
generator next; atEnd
"==> true"

Also, this change set will break existing Generator instances if you load 
them into your image and it happens to have some.

Levente

On Wed, 12 Apr 2017, Bert Freudenberg wrote:

> Hi all,
> there was an interesting question about Generators on StackOverflow:
> 
> http://stackoverflow.com/questions/43340007/yield-prolog-adaptation-for-smalltalk
> 
> It's about a pseudo-Prolog implementation using Generators and yield.
> 
> Our Generator *almost* works for this, except there is a little problem with the timing of side-effects:
> 
> | x gen |
> x := 0.
> 
> gen := Generator on: [:g |
> x := 1.
> g yield: nil.
> 
> x := 2.
> g yield: nil.
> 
> x := 3.
> g yield: nil].
> 
> gen do: [:i | Transcript cr; show: x].
> 
> This *should* print '1 2 3' but actually prints '2 3 3'. This is because our Generator is written to support a streaming interface (using atEnd
> and peek) so it always computes one yield ahead.
> 
> In other languages (e.g. JavaScript, Python, C#) this is different, the execution is paused at the current yield statement, not 'before' the next
> one. In general, a generator cannot know if there will be more "yields" without executing more code. In Javascript, 'next' returns both a value
> and a 'done' flag, and if the flag is true, the returned value must not be used.
> 
> IMHO we should fix this - see attached changeset Marcel and I came up with. We did not fix the tests yet, but the behavior seems right.
> 
> Even though generators are in the image for a long time they are not used widely yet (AFAIK) so maybe we can still change the behavior? What do
> people think?
> 
> - Bert & Marcel -
> 
> 
>