> 2) The SRFI 140 istring? predicate is replaced with an mstring? predicate. This returns #t on any string that is in fact mutable; on systems without a distinction it returns #t on all strings.
Ok - I don't feel strongly about this. Is this any different from allowing systems without a distinction to have istring? return #f on all strings?
I thought so, but I'm not quite sure why any more. I'll think about it further.
> 4) The SRFI 140 procedures string-upcase, string-downcase, string-foldcase, and substring are renamed to istring-upcase, istring-downcase, istring-foldcase, and isubstring respectively. In that way they do not collide with the R7RS versions, which return mutable strings. In implementations without a distinction, these procedures are of course the same.
Note these are not the only R7RS strings which SRFI 140 specifies to return immutable strings.
There is also (at least) string-append and list->string.
Yes, I meant to include all of them.
I have mixed feelings about this issue. Backward compatibility is always desirable, but there are
costs. Having to change existing programs to use istring-upcase/.../isubstring is also a compatibility
issue: Old programs that continue to use string-upcase/.../substring may continue to produce the same
result, but may be much slower than expected.
Since there are no performance guarantees in R7RS, and systems without the distinction would not
be able to do better, it's a purely optional optimization. You should make use of whichever procedure is
semantically correct, and you will get the improved performance on some systems but not others.
That, plus simplicity, is why I think on the whole the SRFI 140 compatibility-breaking is the
better option. A compromise may be to use libraries: If you import (srfi xxx) or (r7rs-large) you
would have string-upcase/.../substring return immutable strings; if you import (scheme base) or
(scheme char) you get the r7rs semantics.
I'll think on that further. It breaks a current invariant, which is that no R7RS-large library
has names that conflict with any others. I know this is important to many people not have
to use "only" and "except" when dealing only with standard identifiers.
> 5) A new make-istring procedure is added to create immutable strings that consist of the same character repeated: the fill argument is required rather than optional.
This is redundant with SRFI 140's string-repeat, which allows the first argument to be *either* a character
or a string. I'd rather than string-repeat.
Agreed.
> 6) The SRFI 118/140 procedures string-append! and string-replace! are made into linear-update procedures: that is, they always return a mutable string, which may or may not be the same (in the sense of eqv?) to the argument string.
I'm skeptical of linear-update procedures, especially when their names don't make it
clear what is going on: It is too easy to forget to add the set! - programs developed on
platforms that update in-place (which is probably most of them) will fail on platforms
that don't update in-place.
I think that *most* platforms will *not* provide adjustable-length strings, though perhaps many
platforms *could* provide them. Chicken at least cannot, because the characters are appended
directly to the string object header.
Most programmers are not familiar with linear-update procedures
Anyone who knows how to use SRFI 1 (e.g. reverse!)
has to understand how to use linear-update procedures.
I'm particularly opposed to re-purposing the names string-append! and string-replace! as that
breaks Kawa programs that use them. I have no problems with the names string-append-linear! and
string-replace-linear!.
Works for me if string-append! and string-replace! are removed from the new SRFI.
Another possibility is that the old names be macros:
That makes "apply" unusable, which I dislike.
--