Comments

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

I don't agree with Murray's three cirteria for what should go into the
language.  I think a reasonable fourth criterion is:

4) The proposed construct will be used a lot, represents some
abstraction that is easy to grasp, and code using it is
clearer than the equivalent lower-level stuff appearing inline.

Actually, that's a criterion that every programmer should use in deciding
whether to create a new function or macro, but if the "used a lot" part
applies to the Common Lisp community as a whole and not just to one or
two application programs, then it is worthwhile putting this new thing
in.

This leads to a large language, but one in which there are lots of
useful constructs and one in which it is much easier for person A to
read person B's code.  Murray's rules would lead to a very lean
language, perhaps easier to learn and a little bit easier to implement,
but not so good for heavy duty programming.  For better or for worse, we
decided years ago that Common Lisp would include a lot of these optional
things.  That is why, for example, we include all the sequence functions
that could just as easily have been written as DO's (or as PROG's and
GO's, for that matter.)

Of course, we've got to stop somewhere.  Constructs whose usefulness is
unclear don't make it, nor do constructs where each person wants
something a little bit different and where there is no general agreement
on how to bundle these different versions into a single clear package.
If an item is controversial, but is implementable in a strictly portable
way, we generally suggest that it be put into a Yellow Pages library
until we see if it is going to "take" or not.

I don't like XOR because it doesn't look generally useful to me and
because it can be quite confusing to deal with.  There are several
closely-related things that XOR might mean (only one versus odd parity,
for example) and the parallelism with AND and OR breaks down in
some ugly ways.

-- Scott