This page is part of the web mail archives of SRFI 40 from before July 7th, 2015. The new archives for SRFI 40 contain all messages, not just those from before July 7th, 2015.
On Monday, February 17, 2003 8:52 AM, Matthias Neubauer [SMTP:neubauer@xxxxxxxxxxxxxxxxxxxxxxxxxx] wrote:
> STREAM-ITERATE computes a subsequent element of a stream, x_{i+1},
> using its previous element, x_i, as sole input to the function
> FUNC. The following ascii scribble should help to illustrate this:
>
> x_0 -FUNC-> x_1 -FUNC-> x_2 -FUNC-> ... x_i -FUNC-> x_{i+1} ...
>
> STREAM-UNFOLD on the other hand does not only rely on the previous
> element for each computation step but it instead passes an additional
> "state" s_i from step to step:
>
> /-> x_1 /-> x_2 /-> x_i /-> x_{i+1}
> s_0 -FUNC--> s_1 -FUNC--> s_2 -FUNC--> ... s_i -FUNC--> s_{i+1}
>
> The big win with the second approach is, that the passed state can be
> of any type (i.e., it does not have to coincide with the type of
> stream elements at all) and thus can also hold some additional
> information needed to compute the next element besides the stream
> elements.
I'm sorry. I didn't read your original message closely enough. Yes,
stream-unfold is more fundamental than stream-iterate. I'll add this
in future versions of the SRFI.
Phil