On 2/24/20 12:09 PM, John Cowan wrote:
> If you prefer me to remove your name altogether, I can with your permission.

I'd like you to remove me as "original author", and not list me in the index/front page.

The "Author" section could say "much of the text and examples is derived from
SRFI-118 by Per Bothner" if Arthur thinks that is appropriate.

I've done some more thinking about this, and I've convinced myself that linear-update
APIs is an elegant but misguided idea.  They should not be used in new APIs or added to
programming-language libraries.  They are harder to use correctly, have unpredictable
performance and behavior, are error prone, and confusing for non-expert programmers -
doubly so if the idea is only used for a few new procedures.  A string library should
be purely functional, or un-apologetically side-effecting.  Linear update is
wishy-washy and has none of the benefits and all of the downsides of either model.

One perceived advantage of string-linear-append! is that it can be implemented
portably on unmodified legacy Scheme systems - but at the cost of both unpredictable
performance and unclear semantics.  If we're trying to define "R7RS-large" that
perceived advantage should not be leading us to specifying a worse API: If people
have to change their string implementation, so be it.  (They probably had to do
that for Unicode anyway.)  If we're trying to define a "portability layer" (shim)
then my suggestion to define a SRFI-118 "subset" where string-append! and
string-replace! are macros works just as well.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/