[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strings rationale
From: |
Tom Lord |
Subject: |
Re: strings rationale |
Date: |
Mon, 6 Aug 2001 15:11:04 -0700 (PDT) |
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.
Thanks. That's completely clear now, though still a little confused
("symbol->string"? regexp matches"?). You're mixing up shared strings
and read-only strings. They are different.
No, you don't have to check for read-onliness before using
`string-set!'. `string-set!' checks internally, and signals an error
if passed an immutable string.
In general, your program will have strings that you know should never
be modified -- those can be read-only strings whenever it is
convenient. Calls to `read-only-string?' are only rarely needed.
Here is a trivial example:
(string-append 'hello " " 'world)
There is no overhead anywhere in there associated with using symbols
as strings. [As a subtlety: Some memory might be saved. Some hash
table space may be lost. It isn't a feature you can use in your sleep
-- but it isn't a feature that causes lots of headaches, either.]
From an efficiency perspective, you're making extra checks on
all string mutators
Not really. Clever choice of tags fixes that. At worst, you're
adding fewer than 10 instructions to functions that cost several
orders of magnitude more than 10 instructions.
I'm just arguing that without proof you shouldn't claim
read-only strings are in general more efficient
Good. Apply that argument to the elimination of gloc's too, please.
My proof (about the cost of read only strings) is the implementation
in Systas Scheme. You can see its cost by reading the code.
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.
You have to think about whether a given string is supposed to be
mutated regardless of whether or not that string is mutable, so
there is no extra burdon here.
-t
- strings rationale, Tom Lord, 2001/08/06
- Re: strings rationale, Neil Jerram, 2001/08/06
- Re: strings rationale, Alex Shinn, 2001/08/06
- Re: strings rationale, Tom Lord, 2001/08/06
- Re: strings rationale, Alex Shinn, 2001/08/06
- Re: strings rationale,
Tom Lord <=
- Re: strings rationale, Eric E Moore, 2001/08/06
- making up language features, Tom Lord, 2001/08/06
- Message not available
- apologies, Tom Lord, 2001/08/06
- Re: apologies, Neil Jerram, 2001/08/11
- 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