This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RO-strings in Guile


Since we're now talking about changing the internal representation of
strings (and, I assume, symbols), it seems to be a suitable time to
bring the following into the discussion:

In a previous discussion we came to the conclusion that an R4RS
function like `string-append' shouldn't take both strings and symbols
as arguments.

Nevertheless, with the current representation of strings, this is just
a matter of argument checking when the implementation is concerned.

And since it sometimes can make code more efficient (avoiding
unnecessary allocation) to treat symbols directly as strings, I'd like
to point out that we could keep the read-only string concept
internally in the interpreter, but provide new primitives for making
use of it at the scheme level.  (I know people here at KTH who have
very happily started using the string <=> symbol property of the
current Guile.)

As an example of what I mean:

(string-append "a:" 'b) --> error

(string-append "a:" (symbol->string 'b)) -> "a:b"
[yes, this is articifial]

(const-string-append "a:" 'b) --> "a:b"

To avoid distribution bloat, `const-string-append' & co could be
distributed in a separate package containing miscellaneous
functionality aimed at people who prefer power over slimness.

Internally, functions implementing these string operations would be
split into two functions: A wrapper with argument checking which calls
a function implementing the core functionality.  This "core" function
could also be called directly by code produced by certain types of
compilers.

/mdj