read'ing/write'ing strings, and escape sequences

[Jacques A. Vidrine]

Hello,

I'm new to the list, but in the past few days I've noted that there is
an impending release.  I had planned to  bring this up only when I had
patches  also, but  noting the  release I'm  now more  anxious to  see
whether folks think the following is worthwhile.

This is actually two tightly coupled proposals.

The first is that the string read syntax be expanded to support
all of the escapes found in ANSI C.  Currently we have:

   \" \\ \n \0 \f \r \t \a \v 

I would like to add:

   \' \? \b
   
as well as:

   \[0-9]{1,3}          octal representation
   \x[0-9]{1,2}         hexidecimal representation

The second proposal  is to provide some way to  write strings with all
non-printable characters represented as above.   This helps a lot with
debugging. e.g.:

   (write "Hello\0with\0nulls\0")
   --> "Hello\0with\0nulls\0"

This makes  it possible  for a  human to  tell the  difference between
"ab", "a\0b", and  "ab\0\0\0"... when working with write  output or at
the interactive REPL.

I don't think I can just change `write' to do what I want.  That would
cause at least one problem [1]: `write' would produce strings that are
not  read  syntax  compatible  with  R5RS [2].   On  the  other  hand,
providing a separate function for printing  strings in this way is not
very useful (although easy to implement in Scheme).

So I think that  making it an options would be the  right thing to do.
But where?  We have `read-options', but not `write-options' :-)

Thanks for reading this far.  Please let me know your thoughts.

Cheers,
-- 
Jacques Vidrine / address@hidden / address@hidden / address@hidden

[1] Well, there is one other minor issue: writing the bytes out as-is,
    as  is  currently done,  is  more  efficient than  converting  the
    non-printable characters to ASCII escape sequences.  Someone might
    care, I guess.

[2] R5RS defines only \\ and \";  ``Scheme does not specify the effect
    of  a  backslash  within  a  string that  is  not  followed  by  a
    doublequote or backslash.''