Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.lang.lisp
Subject: Re: A BNF for Lisp
Message-ID: <555@mit-eddie.UUCP>
Date: Sat, 23-Nov-85 17:47:26 EST
Article-I.D.: mit-eddi.555
Posted: Sat Nov 23 17:47:26 1985
Date-Received: Sun, 24-Nov-85 11:11:01 EST
References: <60@aquila.UUCP> <68@nbs-amrf.UUCP> <63@aquila.UUCP>
Reply-To: barmar@mit-eddie.UUCP (Barry Margolin)
Organization: MIT, Cambridge, MA
Lines: 49

In article <63@aquila.UUCP> chris@aquila.UUCP () writes:
>Read macros can safely be ignored by the BNF because they ARE macros;

Unfortunately, this is not really true.  Read macros can do
arbitrary computations and may have side-effects; '#.form' is defined to
evalute 'form' at read time.  A user-written read macro may be even more
complex.  Also, splicing read macros may be used to have a read
macro expand into any number of objects, while the macros that chris
describes always turn into one object.  Finally, a grammar that doesn't
know about read macros doesn't know how many of the original tokens
translate into a single lisp object.

>the Lisp reader still gets (after macro processing) a valid sequence of
>tokens that is handled by the BNF. That is, 'A ==> (quote A). (Q.E.D.)
>(And don't tell me about back-quote; `(a b ,c ,@d ...) is an EVALUATION
>mechanism. The Reader produces something like (back-quote (a b (comma a)
>(comma-at d) ...)), which is a valid form for later EVALUATION).

This is true of some implementations of backquote, but not the Maclisp
one.  In Maclisp, the backquoted expression might translate into (append
(list 'a 'b c) d ...).  However, '#+LISPM (send window :init)' turns
into absolutely nothing (like a comment) at read time on anything other
than a Lisp Machine.  But my main point is that a macro-ignorant parser
would not realize that the above expression is one s-expression; a
simple-minded scanner would treat that as two or three s-expressions.

>Note that just because Lisp places the read macro
>handling in the reader does not mean it has to be there; as C programmers
>know, macro scanning can be done in another program entirely so long
>as valid code is produced. Of course, the Lisp macros are more powerful
>because they ARE in the language; however, this greater power is rarely used.
>An example would be a read macro that generates different code depending
>on the value of some other Lisp symbol; such a macro would be confusing
>to debug and dangerous to use in most cases. You can write one if you want
>to try convince me of its utility.

As I mentioned above, one of the standard macros in Maclisp, Zetalisp,
and Common Lisp is #+, which is designed to permit read-time
conditionalization based on the environment.  The intent is to allow a
program designed to be run in various environments with different
syntaxes for to work.  For instance, one might write
	(setq variable #+LISPM 123s4 #-LISPM 123e4)
("123s4" is Zetalisp syntax for a small-float with the value 123x10^4,
but other Lisps may not have small-floats and they may choke on the
syntax).
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar