[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Forwarded message and reply
- Subject: Re: Forwarded message and reply
- From: Guy.Steele at CMU-10A
- Date: Tue ,30 Dec 80 13:22:00 EDT
Date: 21 December 1980 14:46-EST
From: Carl W. Hoffman <CWH at MIT-MC>
Subject: Once again a plea for slash
From: Guy.Steele at CMU-10A
I am firmly convinced that the MacLISP-and-sons community would be
much better off if we were to change the "slash" character to something
other than "/". The sooner we do it, the better.
I agree with everything you say in this proposal. I am even willing to
convert Macsyma and help convert Multics Emacs, which would be two of the
larger bodies of code affected, as well as all of my own programs.
I would make one change, however. If we adopt \ as our quoting character,
then I would make the "character reader" be #/. If we stick with / as the
quoting character, then the character reader should be #\.
My reason? I would like to define the quoting character (let's call it /
for now) as follows: When a / is encountered, the following character is
read and is treated as if it had the same syntax as an uppercase
alphabetic. This is almost what the current definition is, with the
exception of the treatment of #/. That is, I feel that #/A should be the
same thing as #A.
Take a look at the Lisp Machine reader. / has the definition I gave
above. / is processed at a very low level. As a result, #/ is defined
using a kludge. The regular expressions which recognize #q, #o, and #\
forms look something like
# Q <form>
# O <integer>
# \ <symbol>
This of course is highly schematic. However, the expression which
recognizes #/ looks like
# <slashified-character>
Do you see what I'm driving at? Slashification is done before the
tokenizing FSM is run. The definition I would like to adopt would also
simplify the coding of editors and other programs which parse Lisp code.
Of course, the reason that #/ was used in the first place is that,
while it makes it harder if you did indeed put /-handling at that low
a level, it makes it much easier for very simple-minded parsers (like
EMACS) to deal with the syntax. Maybe the current organization of the
LISPM reader isn't appropriate to the task? The trouble is that it
treats #/A as #[/A] rather than as [#/]A. The idea is that #/ is an odd
kind of /, just as #' is an odd kind of '.