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!.
I'll modify the second implementation in 185 to always return the result independently of what string-append! and string-replace! return. That makes them result-type compatible with string-append and string-replace.
I'll also add the set! to the examples as you suggest.
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.
Except that you cannot invoke `apply` on them, which I consider an important limitation.
My suggestion: Define a new SRFI that is the same as SRFI-118, except
that string-replace! and string-append! are syntax.
That's a perfectly reasonable thing to do, but I'm not going to be the person who does it.
If you're going to put my name on this, you should note my
lack of endorsement.
Your name is on it because you wrote most of it, but I will add a no-endorsement section.
On Mon, Feb 24, 2020 at 2:06 PM Marc Nieper-Wißkirchen <
xxxxxx@nieper-wisskirchen.de> wrote:
From a theoretical point of view, I like the idea of linear update procedures alot; what is missing is a way to communicate warnings if certain results are not used (like in gcc's unused-result warning.
This is just the ability to declare optional static types. If a procedure is declared as returning an unspecified value, then you get a type warning if you try to use the value. Per contra, if it is declared to return a value, then you get a type warning if you do not use the value.