Jim Rees scripsit:

> A minor nit that I'm only slightly concerned with:  The optional
> arguments to string-unfold and string-unfold-right -- we already don't
> like optional args unless the justification is sufficient.

True, but the cost of unused optional arguments is very small: basically
you just pass (), which does not need to be allocated.

> In this case, the caller could easily just use string-append on the
> output of string-unfold without those arguments.

That requires copying the whole generated string.  Providing initial and
make-final arguments allows you to bracket the string with delimiters
without having to copy it.

> But of greater concern -- with respect to the optional shared-storage
> functionality -- it would be helpful if the proposal discussed how
> this relates to mutable & immutable strings on input and output, as
> well as any limitations or requirements on the semantics of shared
> storage.  The only user-observable effects of shared-storage as I see
> it would be that mutations to one string are observed in the other OR
> that the complete substring of one string is eq? to the other.  The
> first effect - propagated mutations -- is that really desirable here?
> If all strings were immutable, this would be a non-issue.

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.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
                .e'osai ko sarji la lojban.
                Please support Lojban!          http://www.lojban.org