[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Here strings?

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.



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