Shiro,

On 2023-02-11 14:05 -1000, Shiro Kawai wrote:
> Regarding the order of effects, I have an opinion.  The design choice of
> lseq is to loosen the strict laziness to get efficiency.  Srfi-127 is
> inspired by Gauche's lseq, which in turn is inspired by Clojure's seq.  I
> believe Clojure may realize seq's elements in a chunk, e.g. 32 elements at
> a time, at least in some situations.  So you shouldn't rely on the timing
> of evaluation anyway; all that's guaranteed is that the data is available
> by the time you accessed it, and the whole thing runs in a bounded space if
> you don't keep the previous elements.  I think lseq should be used in the
> same way, that is, you shouldn't rely on that (lseq-for-each write-char
> chars) prints "read write read write ..."; it may print "read read write
> write read read write ...".   But of course, you should be able to pass an
> infinite lseq to lseq-for-each and expect proc to be definitely called.

Thanks for discussing this in detail. I agree that strictly specifying
the order of effects may not be good, and that an implementor should be
able to use some kind of “buffered forcing”. We could spend a lot of space
discussing the subtleties of effectful lazy sequences, though, and I wonder
if this semantic change is too big to add as a post-finalization note.
While lseq-for-each is hit hardest, the issue affects every form in the
SRFI.

Do generators need refined semantics, too?

I understand that it’s a difficult time for John and that we may have to
wait for his opinions on this.

Regards, Wolf

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>