SRFI 185: Linear adjustable-size strings Arthur A. Gleckler (24 Feb 2020 18:18 UTC)
Re: SRFI 185: Linear adjustable-size strings Per Bothner (24 Feb 2020 18:53 UTC)
Re: SRFI 185: Linear adjustable-size strings Marc Nieper-Wißkirchen (24 Feb 2020 19:06 UTC)
Re: SRFI 185: Linear adjustable-size strings Per Bothner (24 Feb 2020 19:31 UTC)
Re: SRFI 185: Linear adjustable-size strings John Cowan (24 Feb 2020 20:09 UTC)
Re: SRFI 185: Linear adjustable-size strings Per Bothner (25 Feb 2020 01:08 UTC)
Re: SRFI 185: Linear adjustable-size strings Arthur A. Gleckler (25 Feb 2020 06:00 UTC)
Re: SRFI 185: Linear adjustable-size strings Arthur A. Gleckler (24 Feb 2020 19:14 UTC)
Re: SRFI 185: Linear adjustable-size strings John Cowan (24 Feb 2020 19:21 UTC)
Re: SRFI 185: Linear adjustable-size strings Marc Nieper-Wißkirchen (24 Feb 2020 19:54 UTC)

Re: SRFI 185: Linear adjustable-size strings Per Bothner 24 Feb 2020 18:53 UTC

Am I missing something in the translate-space-to-newline example?
There seems to be a missing
     (set! result ....)
wrapping each call to string-linear-append!.

FWIW: I've expressed before my skepticism of linear-update procedures.
I think it's an inherently hard-to-use error-prone way of working.
Changing string-replace! and string-append! to macros would have
the same portability and performance benefits.

My suggestion: Define a new SRFI that is the same as SRFI-118, except
that string-replace! and string-append! are syntax.
On a Kawa-like-system:

(define-syntax string-append!
   (syntax-rules ()
     ((_ r s ...)
      (begin
        (srfi-118-string-append! r s...)
        (set! r r) ;; to catch misuse
        ))))

Portable implementation:

(define-syntax string-append!
   (syntax-rules ()
     ((_ r s ...)
      (set! r (internal-string-linear-append! r s...)))))

If you're going to put my name on this, you should note my
lack of endorsement.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/