Regarding string-unfold, point conceded.

On Mon, Apr 11, 2016 at 6:54 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

As I understand it, the whole point of true shared substrings a la Guile
is so that mutations *are* propagated. I'd love to have only immutable
strings, but that would have been a derogation from IEEE (R4RS) Scheme,
and the bar for that was set very high by our charter.

Right, I didn't intend to suggest that mutable strings go away. It was more like, sharing is hard, because some strings are mutable.

Let me see if I can narrow my concerns to a few specific questions:

1) One implication of the sharing option is that some of those procedures may return immutable strings as results not just when an argument is returned, but when a new object is constructed which refers to storage shared by one or more arguments. Guile does this currently. R7RS-small explicitly limits that feature (immutable strings) to symbol->string and READ. This document doesn't discuss the matter. I'm unsure of what the default expectation is for the sharing procedures and the rest of the procedures in the SRFI.

2) The document already says that string cursors become invalid once a mutation has been performed on the string they came from. Should the same be said if a mutation has been performed on any other string that was the result of a shared substring operation on the string this cursor came from? (or for that matter any "relative" in the tree of substrings with a common original ancestor string?)