This page is part of the web mail archives of SRFI 75 from before July 7th, 2015. The new archives for SRFI 75 contain all messages, not just those from before July 7th, 2015.
John.Cowan wrote:
Here-strings and literal strings both have the same possible range of source representations.Actually not. A here-string can only represent those characters whichcan be represented in the encoding of the Scheme source.
The latter sentence is saying the same thing I was, but I used the term "source representation" as shorthand to say that.
I'm saying that both the source representation of a here-string, and the source representation of a quoted string, can only include those characters which can be represented in the encoding of the Scheme source.
(I'm talking about the representations of these strings in source code or reader data, not about the Scheme strings which the source representations denote.)
For example, if the encoding is ASCII, a here-string cannot represent non-ASCII characters. A quoted string (as extended by SRFI-75) can represent any Unicode character.
Right, but in the source representation itself, both here-strings and quoted strings necessarily have exactly the same possibilities and constraints. However, they are interpreted differently by the Scheme implementation.
Exactly the same limitations apply to XML's CDATA sections vs. ordinary character content: no escaping required, but none permitted either.
Yes, although as I pointed out, here-strings can support any sort of escaping you desire, merely by processing them through a procedure which performs the desired escape sequence translation. Ordinary literal strings can be thought of as here-strings which are always processed through a specific procedure, the SRFI-75 escape sequence translator.
It's explicitly out of SRFI-75's scope what encodings of source code R6RS implementations must accept.
Yes. Anton