Re: strings rationale

[Alex Shinn]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Alex> The inconvenience [of read-only-string?] is in the need to
    Alex> use those predicates.  If strings can be shared, you need to
    Alex> check for this before modifying them.

    Tom> Please explain more carefully what you mean by this cryptic
    Tom> comment.  It makes no sense to me.

Sorry, writing more as a guile-user here than a developer, and I may
indeed be misunderstanding this.  But it seems that if you're passing
around read-only strings (whether through direct creation,
symbol->strings or regexp matches), then whenever you want to mutate a
string (e.g. via string-set!) you have to test to see if the string is
read-only.  Unless, of course, we add copy-on-write, but then you're
still testing for read-only strings, just moving the logic to a lower
level.  From an efficiency perspective, you're making extra checks on
all string mutators, which could make things slower (not necessarily,
I'm just arguing that without proof you shouldn't claim read-only
strings are in general more efficient).  From a convenience
perspective, a programmer has to juggle in his mind whether strings
can be read-only or shared and what effect mutators will have on them.
Even with copy-on-write, if you wanted to wrap a C library function
that mutates strings you'll have to add in the copy-on-write logic
yourself (or create and convince people to use a new alternative to
SCM_STRING_CHARS for use with mutators).

Please correct me if I'm completely off base and I'll shut up :)

-- 
Alex Shinn <address@hidden>