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