I completely missed that changes from srfi-13; Gauche also uses
srfi-13's procedures as is, that don't handle the case when mapper
returns a string.

And it's not only string-unfold / string-unfold-right.   SRFI-152's
string-map also allows proc to return a string (even it is shown in
the example).

My guess is that it had in mind the case like mapping #\ß (U+00DF) to
"SS", or #\ヸ (U+30F8) to "ゐ◌゙" (U+3090 U+3099).  string-unfold may
want to generate multiple codepoints per seed.

But that seems an incomplete solution, for most other string scanning
procedures walks codepoint by codepoint.  What we want would be some
kind of grapheme-unfold / grapheme-map etc.

On Thu, Oct 15, 2026 at 4:53 AM Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz> wrote:
>
> Hi John & the SRFI 152 list,
>
> While transcribing the SRFI for R7RS-large, I noticed that it added
> string-character polymorphism to ‘string-unfold’ and (by analogy)
> ‘string-unfold-right’.  That is, the ‘mapper’ and ‘make-final’ procedures
> used by these unfolds are allowed to return a string or a character, and
> the ‘base’ parameter may be of either type.  The SRFI 13 versions insist
> on characters for string elements, and strings for string portions.
>
> There is no rationale for this extension and no example of its
> application, and it’s probable no one has ever used it: the
> sample implementation doesn’t implement it.  (The string-unfold
> implementations are identical to those of the SRFI 13 forms.)  The
> text is also incompletely adapted.  The SRFI says that “‘base’ is the
> optional initial/leftmost portion of the constructed string” and that
> “‘make-final’ … produce[s] the final/rightmost portion …”.  This is
> the SRFI 13 language, used in a situation where the “portions” are
> always strings.  We (or maybe just I) generally think of characters
> as *elements* of strings.
>
> So either the sample implementation needs to be fixed (replaced, really,
> since it’s one of Olin’s “highly tuned” jobs) or the unfolds need to
> be reverted to their SRFI 13 versions.  (A very big erratum.)  If we
> do change the implementation to match the SRFI document, implementers
> need to know about it.  The SRFI 152 sample implementation, rather
> than the specification, has propagated, so that not one ‘string-unfold’
> I tried supported the given semantics.
>
> Wolfgang
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>