For Loop and lazy(/batched) processing

[Raphael Collet]

Denys Duchier wrote:
> Few may know that (in the devel trunk) I have added the (experimental) "yield"
> and "yieldAppend" keywords to the loop construct:
> 
> If "yield" (and/or "yieldAppend") appears in a "for" loop, this loop is
> automatically spawned on its own thread, and each element is generated on demand
> (using WaitNeeded).  This is very much "like" what happens in Python.

Except that Python has no threads and no by-need sync.  The presence of 
the "yield" keyword turns an expression into a generator object.

Can you give us a precise definition of "yield" in Oz "for" loops, in 
terms of Kernel language?  It is still not clear to me.  Ideally you 
should not compute the result *before* it is actually needed.

> I think "yield" is a good idea, but it should be supplemented with a means of
> controlling the "batch" step described in my idea for "on-demand batch" stream
> processing.  For example, let's imagine a "yieldBy" loop keyword that tells us
> the desired batch size:

Ok, fine.

> I think that the "yield" keyword is a nice addition to the "for" loop support,
> in keeping with similar additions to e.g. Python.  "yieldBy" would allow us to
> control how many elements to "Yield" before the thread actually suspends.

> PS: another issue with "yield" support is that the stream being generated is
> generated "safely" (i.e. with read-only variables).  This is quite expensive,
> and maybe it would be worthwhile to (occasionally) turn this security feature
> off in the interests of efficiency.  In practice, there are important, yet very
> few, occasions where stream safety is paramount (because streams tend to be
> intermediate data-structures that cannot be subverted).

I have some ideas on a better implementation of read-onlys, which would 
partly solve your issue.  We could remove the context switch that is 
required to bind the read-only view of a variable.

Cheers,
raph