Aubrey Jaffer wrote:
> Can a Here-string be used anywhere a literal string constant can be
> used?

Yes.  Here-strings don't introduce a new data type, merely a new way to
represent literal strings.

> Can a literal string constant be used anywhere a Here-string can be
> used?

Yes.

> With the escaping conventions being discussed, will Here-strings and
> literal string constants be able to code the same set of possible
> strings?

The point of here-strings in the SRFI-75 context is to be able to embed
unescaped text, so that it is not necessary to quote characters such as
quotes and backslashes within a here-string.  Here-strings and literal
strings both have the same possible range of source representations.

However, ordinary literal strings undergo a conversion process in which
a predefined set of escape sequences are converted by the Scheme
implementation.  Here-strings do not undergo such a process.

If you want to use here-strings to create strings that can't be directly
represented in source code, you can process them through a procedure
which performs whatever escape sequence translation you'd like.  In
fact, ordinary literal strings could be defined in terms of such a
function on here-strings:

"foo" =>

(translate-srfi-75-escapes #<<END
foo
END
)

So, think of ordinary literal strings as shortcut syntax for a
particular kind of escape processing on here-strings.

> When a string is the argument to the WRITE procedure, is a
> double-quoted or Here-string written?

I guess that hasn't been defined yet, but printing a double-quoted
string with appropriate escapes would be a reasonable behavior.

Anton