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] |
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