Guidelines for the Standard

[Christopher Fry <cfry@OZ.AI.MIT.EDU>]

    One could also argue (weakly)
No, probably strongly! 
    that this language is
    doomed to a certain amount of inconsistency in naming and argument
    order.  Any set of rules you establish for this is going to break down
    in certain places.
Yeah but we could be a lot more consistent than we are now.
I meant only to eliminate unnecessary inconsistency such as
nth takes it's index as the first arg and elt takes its
index as the 2nd arg. 
[Below I propose flushing NTH which solves this particular inconsistency.]

    (-: By the way, how else would you spell RPLACA?  We kept this around
    mostly as a historical monument, and any tampering would amount to
    desecration.
Here in Boston we have a place called the Computer Museum.
I'm sure we could find an honorable resting place for RPLACA there.  
    It does an ugly thing, so it should be ugly.
Well, you've got a point. Frequently new cars are uglier than old ones
so replacing your old car can be ugly.  
    Only wimps
    use Setf of Car.  But we artists are allowed to differ in matters of
    aesthetic judgement. :-)
Touche! I forgot that ART can be used to argue both sides of any dispute.
......

I'd flush both rplaca AND car.
(setf (elt foo) new-value)
where the 2nd arg to elt defaults to 0.

And, in case you're wondering about rplacd...
(setf (rest foo) new-value)
I'd extend rest to take an optional 2nd arg of index
so that we could flush cdr AND nthcdr. This new arg to
rest defaults to 1.  [A value of 0 just returns the first arg]

I'd also flush the rest of the car and cdr derived fns,
as well as first -> tenth and nth [use elt instead].

The above proposals eliminate 42 functions from CL,
whose functionality is pretty easily accomodated by
the addition of 1 optional arg to each of 2 existing
functions. [Readers of Hitchikers Guide to the Galaxy can now
infer the question to which the answer is 42.]

If you tell me that CADAR functionality is essential to CL,
then I'd propose that elt be able to take a list of
integers which specifies a "list-path" to get to any
arbitrary element or cons of a [nested] list.
With this notation, we could flush REST too,
[my list-path notation allows the specification of
 tails of lists as well]
but I'm not sure I'm willing to go to THAT extreme.
[Though it would bring the total up to 43].

elt vs nth as far as efficency is concerned can be
fixed with a declaration, when you really care.
A smart compiler can turn (elt foo 1) into the same code
as (cadr foo). Notice there is exactly 1 character difference
in length for those of you concerned about typing.

Getting just a little fancier, a negative index to
elt or rest could index from the END of the list instead of
the beginning. Thus
(rest foo -1) is equivalent to (last foo) .
[I'm up to 44]
These negative indicies have the disadvantage of missing
a common error check, like for instance, when
you're in a loop decrimenting the index and using that
index in a call to NTH, you'd like something to tell you
if your index goes illegally below 0. This could be
fixed by having an optional 3rd arg PERMIT-NEGATIVE-INDEX?
which defaults to t, and is primarily used by the compiler.
But you still need to check ranges for too positive or too
negative anyway so maybe this point is moot.

......
As was pointed out during the subset discussion recently
[I think by RAM], eliminating these forty odd functions 
would not decrease the size of an implementation of CL
by 44/620. It would make it a little smaller, but 
it would make it easier for people to learn to code in CL 
and, even more dramatically, make it easier to read CL.
There are other redundancies and inconsistencies in
CL of negative value. The above is just an example of
the kinds of mods that could be made. Do I hear 45?

ps: I've already implemented all the stuff I've proposed
cutting so this isn't saving me any work.