Implementation of lseq-for-each Wolfgang Corcoran-Mathe (11 Feb 2023 18:11 UTC)
Re: Implementation of lseq-for-each Shiro Kawai (12 Feb 2023 00:05 UTC)
Re: Implementation of lseq-for-each John Cowan (12 Feb 2023 15:47 UTC)
Re: Implementation of lseq-for-each Wolfgang Corcoran-Mathe (13 Feb 2023 18:38 UTC)
Re: Implementation of lseq-for-each Arthur A. Gleckler (14 Feb 2023 04:27 UTC)
Re: Implementation of lseq-for-each John Cowan (17 Feb 2023 21:46 UTC)
Re: Implementation of lseq-for-each Wolfgang Corcoran-Mathe (27 Feb 2023 23:01 UTC)
Re: Implementation of lseq-for-each John Cowan (28 Feb 2023 00:37 UTC)

Re: Implementation of lseq-for-each Wolfgang Corcoran-Mathe 27 Feb 2023 23:01 UTC

On 2023-02-17 16:46 -0500, John Cowan wrote:
> On Mon, Feb 13, 2023 at 1:38 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> wrote:
>
> > 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”.
> >
>
> It doesn't seem right to talk about the *order* of effects.  The first
> effect should happen first, the second effect second, and so on.  What
> should be unspecified is *how many* effects happen on each iteration.

At first I disagreed, and now I think I agree. But I’m not sure whether
this is the right way to explain what, exactly, is unspecified. The
author of (lseq-for-each proc seq), for example, might like to know
whether proc will be invoked as soon as its argument is available
or after several more values are forced. Knowing the number of effects
that occur on each step is enough to answer this question, but it
takes a little thought to see how.

If any change is to be made, it may be best to say that the number of
lseq elements forced between invocations of proc is unspecified.

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