[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MacLISP name compatibility, and return values of update functions
- To: common-lisp at SU-AI
- Subject: MacLISP name compatibility, and return values of update functions
- From: Jon L White <JONL at MIT-MC>
- Date: Mon, 01 Feb 1982 20:26:00 -0000
[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.