guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: strings rationale


From: Eric E Moore
Subject: Re: strings rationale
Date: 07 Aug 2001 15:16:53 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

Marius> Eric E Moore <address@hidden> writes:
>> (if (not (false-if-exception (string-set! str n #\q))) (begin (set!
>> str (copy-string str)) (string-set! str n q\q)))

Marius> But note that you can't just villy-nilly substitute modifying
Marius> a string with modifying a copy of that string.  These are two
Marius> very different things.  

True, my example is flawed, you cannot, in fact, do that in the
general case.  However it would work in some cases, eg:

; works around bug in do-something-else that requires a q in the string...
(define (do-thing str pos)
  (let ((char (string-ref str pos)))
    (string-set! str pos #\q) 
    (let ((x (do-something-else str)))
      (string-set! str pos char)
      x)))

Questionable style, I admit, unless str is routinely several k or
longer, in which case it'd be pretty weird to have a read-only string
that long, but it is undoubtedly easier to write if you can (safely)
assume all strings are mutable, and it might be a utility function
that sometimes gets called on large buffers, and sometimes on small
strings that could be read-only.

If you can't guarantee the string's mutable, you need to copy it all
the time, or check for mutability.  With copy on write, it would copy
when you need to copy, and on r/w strings, make the change, and un-do
it.  

My point was merely that sometimes things are simpler if all strings
are mutable, and that string-set! throwing an error does not allow you
to wave your hands and say "see, no need to check if it's mutable".

Not to say we definitely want all strings to be mutable, but
string-set! throwing an error on read-only strings, does require
additional checks for robust code, either for read-onlyness, or for
the error.  

RO strings are not a panacea.  They are, like so many things, a
trade-off, some gains, some losses.  Tom may be correct, and the gains
outweigh the losses, but I disagree that having RO strings does not
require, in the general case, additional checks.

  -Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]