Scheme BNF

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Mon, 31 Mar 86 11:14 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	Date: Sat, 29 Mar 86 17:41:34 EST
	From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>

				     ...  But in order to allow (BEGIN) to work,
	we have to add an exception to the description "BEGIN evaluates the
	forms sequentially, and returns the value of the last form" - you have
	to say "...except that if there are no forms, the value is unspecified".
	I have written interpreters and compilers that deal with (BEGIN) and
	they always have an extra conditional in them to be able to deal with
	that as a special case. ...

    The problem is with the form of the English; it blithely assumes that
    there is a last form.  This is actually a fencepost error; we should
    focus on the spaces between the forms, and not the forms themselves.
    After the word BEGIN there is an <unspecified>, and after each subform
    the value of that form appears.  BEGIN forms a sequence r of the
    <unspecified> value and the values of all the forms, and then returns
    (reduce #'(lambda (x y) y) r).  Clear?

I second GLS's motion to make (BEGIN) and (LAMBDA ()) legal. The problem is
no worse than explaining why (AND) and (OR) are valid.

This same issue has come up in a number of Lisp dialects I've worked with.
I've never had a need for (BEGIN), (LAMBDA ()), etc. in a situation where
I cared about the value, so I'd be quite happy to leave the value undefined
as long as side-effects happen correctly. The situation where it comes up
a lot is in program-writing programs. I end up writing:

 `(LAMBDA () ,@(IF (NOT THE-FORMS) '(NIL) THE-FORMS))

when I wish I could write:

 `(LAMBDA () ,@THE-FORMS)