Am So., 14. Juni 2020 um 22:28 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> > That would be definitely wrong. See my example with `generator-unfold' I
> > gave to John.
>
> I wasn't able to find this example in the previous emails.

Has this post reached you by now?

> > If they don't get it right, we should correct them, not introduce the same
> > error here.
>
> This seems like a very long road to go down, one which does not end
> with unfold.  Very few non-mutating Scheme procedures which take
> procedure arguments specify when or how often those procedures will
> be called, from the perspective of calling those procedures for
> side-effects.  You can, of course, *infer* from the spec of say,
> map, that (map proc lis) will call proc (length lis) times, but
> that's, um, a side effect of the specification.  Making this sort of
> assumption concrete will mean changing a lot of specifications,
> I fear.

It very much depends on how careful a SRFI was written. SRFI 1 is
quite explicit, for example. This includes `unfold` in SRFI 1, from
which all other versions have been derived. (By the way, it is also
pretty clear on how often the PROC argument is called in `map`, and
specifies a bit more for `map-in-order`. R7RS-small is also very
explicit including the case of non-local control flow.

>
> Unfold expressions should satisfy certain theorems, but, if you
> expect that assumptions about side-effecting behavior drawn from
> SRFI 1 `unfold' will hold for FOO-unfold, I think you lose.
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "Not all programming languages have a way to write definitions, but
> most do.  Those that do not are for wimps."  --The Great Quux