Subject: Re: backslashes in strings
From: Erik Naggum <erik@naggum.no>
Date: 1999/04/20
Newsgroups: comp.lang.lisp
Message-ID: <3133614673985751@naggum.no>

* Barry Margolin <barmar@bbnplanet.com>
| I wouldn't guarantee that *nothing* will break, but I'm willing to wager
| that it would be extremely rare.  A bare \n should never show up in a
| printed representation produced by Lisp (if a string actually contains \
| followed by n, it will print as "\\n"), and I can't imagine why someone
| would type "\n" intentionally, given that it's equivalent to just typing
| "n".

  for Lisp programmers and Lisp data, your analysis is correct.  however,
  would a Lisp programmer seriously want to pollute his code with \n and
  its ilk?  (that's rhetorical, I know the answer is Emacs Lisp. :)  the
  problem is therefore not so much that it would not occur in regular Lisp,
  as it is that expectations get distorted once this is made available.
  (e.g., confusions between Emacs Lisp and others Lisps.)

  in particular, if \n is used as an embedded newline in some strings, it
  will cause parsing to fail at random when the readtable is standard.  no
  matter how you nuke your own value of *READTABLE* or its contents, there
  will be a time when this will not be what the data expects it to be,
  unless, of course, *READTABLE* is bound with the data so read.  which was
  my point.

| If the user wants to be able to type \n interactively, he'll need to
| assign *READTABLE* rather than just bind it around LOAD or COMPILE-FILE.

  well, I do this with @ for time objects and #" for symbol-names, but
  these do not conflict with the standard reader macros, and it's fairly
  obvious when things break.  reading "foo\nbar" as "foonbar" is a very
  quiet error.

#:Erik