Re: strings rationale

[Tom Lord]

I don't understand your explanation.

Can symbols be used as strings?  Can there be substrings of symbols?

If there are those things, what is "inconvenient" about providing a
predicate that checks whether or not a particular string is a 
symbol or substring of a symbol?  If there aren't those things,
how was eliminating them an improvement?

Eliminating some calls to "symbol->string" is both convenient and
efficient.  That's one of the effects of having read-only strings.

-t


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

       Tom> But the idea of a read-only-string is safe, reasonable,
       Tom> useful, and otherwise good.

   But from the programmer's POV it is an inconvenience.

   It is better and more useful to provide a unified string data type and
   automatically infer mutability etc. from the way that such strings are
   used, so long as this can be achieved safely (i.e. functionally
   correct wrt multithreading) and reasonably (i.e. acceptable
   performance).

   This is what we hope for Guile, and is what lies behind the comment
   about read-only strings disappearing.