Inconsistencies imposing constraints

[JONL at MIT-MC (Jon L White)]

CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

    Date: 12 April 1980 21:11-EST
    From: Alan Bawden <ALAN at MIT-MC>
    Subject: Inconsistency in various DOs
	Date: 12 APR 1980 1819-EST
	From: JONL at MIT-MC (Jon L White)
	.  .  .     The "gain" for flushing
	old-style DO is to free up the constraints on other DOers imposed
	by the syntax which treats an atomic first "argument" as an abbreviated
	variable specification, rather than a "name" for the DO.  
    I don't see how this follows.  Given that other DOers such as DOTIMES
    are written as macros, they are free to expand into anything they
    want, their syntax is entirely up to the macro-writer.
I don't think I wrote that note in such a way to give the impression
that the constraint was due inability to code up the functionality;
rather the problem is popular attitudes as to what are consistent 
extensions, and abbreviations, for DO.  In fact, your "narrow" viewpoint
towards DOTIMES, expressed in just this very note, is such an example.
    Secondly, you are incorrect in stating that the named mumble argument
    was the only "practical point" mentioned.  (Perhaps we differ on the
    definition of "practical".)  The best argument to my mind was the
    complete lack of generality of your suggestion.  To remind you:
      (DOTIMES X ...)		;Does the thing X times BUT
      (DOTIMES (1+ X) ...)		;Doesn't do the thing X+1 times
    I think that (DOTIMES <atom> ...) should be an ERROR! (How novel!)  I
    also think that (PROG <atom> ...) should be an error, but I am too
    late for that one!  
Have you forgotten how DO is generalized?  with the old-style available,
a non-atomic first arg is *not* generalized the way you just did for
DOTIMES.