Comments

[MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA]

  I think the discussion about whether there should be an XOR
function is very much off the mark.  I think the criterion for
including any new  operator in the language should be one of
the following: 
  1) It is not possible to write it in Common Lisp.
  2) It can be implemented MUCH more
     efficiently in an implemention dependant way.
  3) It requires a lot of programming effort (and is generally useful).

As long as an operator is implementable in Common Lisp, your program
would still be portable.
The only problem that could arise is that your function/macro
is called something that later on becomes defined in Common Lisp, with
different syntax/semantics.  But that problem exists with ANY operator
that you define, and packages can deal with it.  Thus I see no reason
to include something like XOR.  The language is certainly big enough
already.  

Other Issues:

  I would like to vehemently disagree with the proposed change
to the mapping functions, such that it is an error to pass them
circular-lists.  A see no advantage to this, and a clear
disadvantage (I use this mechanism, and often find it the clearest
way to express certain computation e.g.
 (mapcar #'two-arg-fun  arg1-list (or extra-arg-list (circular-list NIL))).
Moreoever, any implementation that actually Checked for the error
is certainly a foolish one. 

  It seems to me that the DEFGLOBAL proposal adds more confusion than
it could ever be worth.  If the desire is to create a global variable
without taking chances on doing a dynamic binding of it, then it
seems the informal policy of doing *this* to a dynamic variable
is adequate.  Anyone who does (let ((*something* ...))) is surely
begging to get a dynamic binding.  Moreoever, it would seem to generate
no more efficiency.

;; I vote for eradication of MacroLet.  

  I recall someone has already asked for the inclusion of the
function MACROEXPAND-ALL.  If this hasn't been accepted, I second
the motion on the grounds of criterion 3 above (It requires knowledge
of  special-operators).

  It appears that there is no way to return multiple values from
conditional forms in any useful way. COND,AND,OR don't return
multiple values for their predicate forms, except for the last form.
AND isn't problematic, since if it returns non-nil, it returns the
values of the last form, and hence multiple-values.  It is OR that
is problematic.  I find it unfortunate that something like:
  
  (defun find-it (list parallel-list)
    (cond ((null list) nil)
	  ((and (atom list) (passes-test list))
	   (values list parallel-list))
	  (t (or (find-it (car list) (car parallel-list))
	         (find-it (cdr list) (cdr parallel-list))))))

Won't work since the OR won't return the multiple values
for the first (car) form.  What is most distressing is
that OR WILL return multiple values for the last form.  This
can easily create subtle bugs that are hard to figure out unless
you know of the peculiar behavior of OR.  Of course, you can
give up on multiple-values, but it seems a real problem if you
have to resort to returning Lists in cases like these.

It is therfore my opinion that OR should return multiple values for ALL of it's
forms, or none of them.  If the latter, Multiple-Value-OR can be written
in Common Lisp, but I wonder if it possible to do it more efficiently
in an implementation dependant way?

(BTW: Page 84 of Cltl refers to OR as a Special Form)

Random Functions:

I would also like to suggest the addition of the predicate
FILE-STREAM-P, which if true, would return the file pathname.

On the basis of being implementation dependant (criterion 1), I suggest
three more functions:

FUNCTION-ARGLIST, MACRO-ARGLIST, and FUNCTION-NAME.

These should work for system functions as well as user defined ones.
And for all kinds of functions - closures, compiled, interpreted.

 - Kelly Murray
   University Of Massachusetts