[no subject]

[Jon L White <JONL at MIT-MC>]

Re your query:
  Date: 3 February 1981 18:37-EST
  From: Kent M. Pitman <KMP at MIT-MC>
  I would like to hear strong arguments opposing the following syntax 
  .  .  .
   A bvl is either a symbol or a list. If it is a list, then the car of the
   list is a declaration, the cadr is the object of the declaration (which must
   be a symbol or another declaration), and the remainder are various attribute
  .  .  .
Say, wasn't it you who objected to BNF presentation of syntax?  Aren't you
now using an informal, and hence less precise, version thereof?

But seriously, there are two important considertions, the first being 
succinctness of program presentation, and I'd like to offer a critical 
comment as well as a constructive suggestion related to "succinctness".
To begin with, I can't agree that the huge difference in "amount of paper" 
needed to present the argument list in
   (DEFUN PROBABLY-SEVEN (&OPTIONAL (X 3) (Y 4))
	  (DECLARE (FIXNUM X Y))
	  (+ X Y))
and that needed in
 (DEFUN PROBABLY-SEVEN ((FIXNUM (OPTIONAL X 3))
			(FIXNUM (OPTIONAL Y 4)))
	(+ X Y))
is on a par with the loss of "X+Y" to "(+ X Y)"
Neither is the notion of being "pre-parsed" important -- there should clearly 
already be some function which takes a DEFUN arglist (and another function
taking a DEFMACRO arglist) and standardizing it into a LAMBDA or LET
format.   Another example of succinctness is in the "destructuring" notion
which has been bandied about recently: notice the difference in coding between
the MacLISP/NIL format
   (DEFUN FOO ((A B C) Y) 
	  ...)
and without it
   (DEFUN FOO (X Y)
     (LET (A B C)
	(SETQ A (CAR Y))
	(SETQ B (CADR Y))
	(SETQ C (CADDR Y))
	...))
*** suggestion ***, wouldn't it be desirable to take another # character and 
use it for generating the kind of argument declaration wanted?  That way, 
people who like the "stickiness" of the existing &keyword style should be 
kept happy, and a compatible extension of the data-directed destructuring
could be done without disrupting anyone's existing code.  For example,
let us suppose that the data-directed destructuring format as shown 
above "loses favor" with users, and they really need some program-
directed format, e.g.
   (DEFUN (`(,A ,B ,C) Y) 
	  ...)
Of course it's pointless to introduce, incompatibly, such a program-directed 
format if its only use it to re-do the data-directed format with more input 
characters required.  But for sake of discussion, let us suppose that
some extension is to be done.  Then, maybe we could let #@ generate the
declaration for program-directed destructuring, and #&x, #&f, #&o, #&s,
and #&r as a prefix for other "declarations", respectively "fixnum",
"flonum", "optional", "special", and "rest".  E.g.

   (DEFUN FOO (#@`(,A ,B ,C) #&x Y #&o #&f Z ((Q . R) (INIT))) 
	  ...)

would read into your proposed format like

   (DEFUN FOO ( (destructure (list (quote A) (quote B) (quote C)))  
		(fixnum Y) 
		(optional (flonum Z))
		(optional (destructure `(,Q . ,R)) (INIT)) )
	...)
[Incidentally, notice my convention of using case information to help 
 distinguish true variables being bound from the declarational "words"]

Now, in order to dissuade the usual inane replies about how awful this
# syntax appears, let me say as did GLS that pointing out possibilities
doesn't mean hot advocacy.  The point is that the succinctness and
"stickiness" of the old style can be preserved by read-macro-ifying
into your list style;  I don't like typing 4 lines and 142. characters
when 1 line and 48. characters is just as clear.  Automatic program
analyzers, like GRINDEF, could display either format, just as it
now has the option of printing either `(,A ,B ,C) or (LIST A B C);
thus I as a user would like to be able to write my code either in
terse or in verbose format.

Now to my second consideration.  The proposal for program-directed 
destructuring as opposed to data-directed, was made partly on the 
supposition that someone, somday, might want to LAMBDA-bind some 
random car of some list cell (as opposed to binding the variable 
found in the data pattern).  This would be a true extension, not 
now primitively obtainable.   Does your proposed syntax buy us 
anything new?  If not, why try to force everyone to conform to it 
-- why not just provide a macro facility which expands your format 
into existing primitives?