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

Re: Forwarded message and reply

    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 '.