guile-devel
[Top][All Lists]
Advanced

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

Re: strings rationale


From: Alex Shinn
Subject: Re: strings rationale
Date: 06 Aug 2001 15:54:33 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104

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

    Tom> Thanks.  That's completely clear now, though still a little
    Tom> confused ("symbol->string"? regexp matches"?).  You're mixing
    Tom> up shared strings and read-only strings.  They are different.

 You used symbol->string as an example of generating read-only
strings, and Rx regexp matches as an example of shared substrings
(which in Guile are read-only).  They are different but have
similarities both in implementation and the "design" complexity that
you need to know they exist.

    Tom> No, you don't have to check for read-onliness before using
    Tom> `string-set!'.  `string-set!'  checks internally, and signals
    Tom> an error if passed an immutable string.

Yes, but you need to test if you don't want it to signal an error (and
instead do a hand rolled copy-on-write).

    Tom> In general, your program will have strings that you know
    Tom> should never be modified -- those can be read-only strings
    Tom> whenever it is convenient.  Calls to `read-only-string?' are
    Tom> only rarely needed.  Here is a trivial example:

    Tom>        (string-append 'hello " " 'world)

But we don't develop trivial examples, we develop complex applications
:) My concern is that once you introduce read-only strings, it isn't
always clear when someone will have optimized some procedure to return
a read-only string, and you will end up having to test for this.

Perhaps an example will help.  Suppose you want to write a mail/news
client.  Naturally you want to incorporate features for the highly
advanced rot13 encryption system popular on Usenet.  You want to
enable automatic processing of large spools, so for efficiency you
won't generate new strings, instead you'll slurp the messages and use
string-set!.  But since this is a solid, full-featured client the
messages are actually processed and broken into a headers section
(where the headers are symbols), and the body (a large string), like
so:

  '(((To . address@hidden) (From . address@hidden))
    . "body of message...")

If you want to loop through this and call rot13 on strings, and rot13
of symbol->string on symbols, it will fail if symbol->string has been
"optimized" to return a read-only copy of the string.

Sorry, that's the best example I could come up with off the top of my
head, but do you see my concern?

    Tom> My proof (about the cost of read only strings) is the
    Tom> implementation in Systas Scheme.  You can see its cost by
    Tom> reading the code.

Pending time to read the code, I'll take your word for it :) The added
programmer complexity, however, seems impossible to get rid of.

-- 
Alex Shinn <address@hidden>




reply via email to

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