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

DRAFT of the Revised Revised Report


(define (number-of-special-forms-in-standard date)
  (expt 2 (date->number date)))

Now seriously,

	Named let corresponds to named-lambda in the same way that let
corresponds to lambda.  If argument list destructuring is not a
problem for let, it is not a problem for named let.  If it is, the
only "destructuring" allowed in lambda is for &rest arguments (dot
notation).  The syntax for LET can be extended to accept rest
arguments:

	Note: Each of the subforms of the binding list of a let must be a
list whose CAR is the identifier and whose CADR is the expression
whose value the identifier will receive.  Thus the syntax can be
extended to the following:

	(let ((<identifier 1> <exp 1>)
	      .
	      .
	      .
	      (<identifier n> <exp n>)
	      <rest identifier>				; Note: no parens
	      <rest exp 1>
	      .
	      .
	      .
	      <rest exp m>)
	  <body>)

	The rest identifier can be recognized by not being in a list,
and all forms following it are the expressions whose values will be
collected into the &rest list.

	I'm not advocating for this extension in the standard, but any
implementation which wants named-let can easily extend the syntax for
let and named-let so that this "destructuring" is provided.

	You may be right in that this means that there are 2 special
forms with the same keyword, but that's alright with me.  I don't want
to have to remember 50 thousand different identifiers which are
"special" to ths system, and I cannot use as identifiers in portable
code since I don't know what happens in all implementations when a
lambda-parameter attempts to shadow them.

	I have no problems recognizing one-armed ifs.  They only
appear in the middle of sequences (sorry, begins) and indentation
allows me to see whether there is a second arm or not.