On 2020-08-21 11:55 -0400, John Cowan wrote:
> The reason to have a special vector flavor of unfold is that vectors aren't
> extensible whereas lists are.  Therefore, it's better if the *vector-unfold
> procedure knows in advance how long the output can get, so that it can
> create the vector to begin with.  If you want a standard unfold, use a list
> unfold and convert to a vector at the end.  Defining this essentially
> compound form as the canonical *vector-unfold imposes that storage
> inefficiency on every caller.

It seems fairly simple: structures that are inductively-defined have
"true", corecursive unfolds.  Those that are not have iterative
("vector-style") unfolds, which take a length rather than a stop?
predicate.

> It's true that strings are also inelastic and string-unfold is the standard
> unfold, but them's the breaks.

It's especially unfortunate that all the string SRFIs follow SRFI 13
in this, since I doubt it's what anyone wants.  Scheme strings/texts
are no longer lists in disguise, and should have an iterative unfold.
As a result of this structural mismatch, I suspect that all existing
string unfolds are unfolding a list and calling list->string, which is
about as good as having no string unfold at all.

This is getting rather far afield, but I think a tiny SRFI to offer an
iterative unfold for strings and texts might be a Good Thing.

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

"The most important computer is the one that rages in our skulls
and ever seeks that satisfactory external emulator." --Alan J. Perlis