[Top][All Lists]
[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>
- apologies, (continued)
- Re: making up language features, Sam Tregar, 2001/08/06
- Re: making up language features, Tom Lord, 2001/08/06
- Re: making up language features, Sam Tregar, 2001/08/06
- Re: making up language features, Klaus Schilling, 2001/08/07
- Re: making up language features, Chris Cramer, 2001/08/07
- Re: making up language features, Thien-Thi Nguyen, 2001/08/15
- Re: strings rationale, Marius Vollmer, 2001/08/06
- Re: strings rationale, Eric E Moore, 2001/08/07
- Re: strings rationale,
Alex Shinn <=
- Re: strings rationale, Marius Vollmer, 2001/08/06
- Re: strings rationale, Rob Browning, 2001/08/15
- was Re: strings rationale, Tom Lord, 2001/08/15