MacLISP name compatibility, and return values of update functions

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

[I meant to CC this to common-lisp earlier -- was just sent to Weinreb.]

    Date: Sunday, 31 January 1982, 14:15-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
    To: Fahlman at CMU-20C, feinberg at CMU-20C
    Would you please go back and read the message I sent a little while ago?
    I belive that it makes more sense to FIRST define a policy about Maclisp
    compatibility and THEN make the specific decisions based on that
    proposal. . .
Uh, what msg -- I've looked through my mail file for a modest distance, and
don't seem to find anything in your msgs to common-lisp that this might refer
to.  I thought we had the general notion of not usurping MacLISP names, unless
EXTREMEMLY good cause could be shown.  For example,
 1) (good cause) The names for type-specific (and "modular") arithmetic
    were usurped by LISPM/SPICE-LISP for the generic arithmetic  (i.e.,
    "+" instead of "PLUS" for generic, and nothing for modular-fixnum).
    Although I don't like this incompatibility, I can see the point about
    using the obvious name for the case that will appear literally tens of
    thousands of times in our code.
 2) (bad cause) LISPM "PRINT" returns a gratuitously-incompatible value.
    There is discussion on this point, with my observation that when it was
    first implemented very few LISPM people were aware of the 1975 change
    to MacLISP (in fact, probalby only Ira Goldstein noticed it at all!)
    Yet no one has offered any estimate of the magnitude of the effects of
    leaving undefined the value of side-effecting and/or updating functions;
    presumably SETQ would have a defined value, and RPLACA/D also for
    backwards compatibity, but what about SETF?
Actually the SETF question introduces the ambiguity of which of the
two possible values to return.  Take for example VSET:  Should (VSET V I X)
return V, by analogy with RPLACA, or should it return X by analyogy with SETQ?
Whatever is decided for update functions in general affects SETF in some
possibly conflicting way.  For this reason alone, RMS's suggestion to have
SETF be the only updator (except for SETQ and RPLACA/RPLACD ??) makes some
sense; presumably then we could afford to leave the value of SETF undefined.