[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: ALAN at MIT-AI, (BUG LISPM) at MIT-AI
- From: RMS at MIT-AI (Richard M. Stallman)
- Date: Sat ,10 May 80 21:13:00 EDT
ALAN@MIT-MC 05/09/80 19:53:52
RMS@MIT-AI 05/09/80 18:04:47
Date: 9 MAY 1980 1634-EDT
From: ALAN at MIT-AI (Alan Bawden)
In system 27.79 nws, with microcode 661, on LISP Machine Six:
The LispMachine should support CASEQ.
What7s wrong with SELECTQ?
Nothing is wrong with SELECTQ. But MacLisp has this thing called
CASEQ which I use because it does the right thing with regard to
fixnums and it was once advertized that CASEQ would be understood by
the compiler. I cannot have SELECTQ expand into a CASEQ because CASEQ
will not let me mix fixnums and symbols. The solution is obvious, on
the LispMachine CASEQ should be a macro that expands into a SELECTQ.
Having two names on the Lisp machine, SELECTQ and CASEQ, for
constructs which are slightly different in a subtle way would be
great lossage, because nobody would remember the difference and
everyone would try to use them interchangeably and get screwed.
If SELECTQ has deficiencies with fixnums, let's just fix that.
The Lisp machine had SELECTQ and the Maclisp people decided to
introduce a gratuitous incompatibility by having something slightly
different and calling it CASEQ. So now there is pressure on
the Lisp machine to follow them in this gratuitous change. They make
lots of gratuitous changes and this will happen every time. If we in
general adopt these changes for the sake of compatibility, we'll be
dragged on a wild goose chase. We ought to decide that we won't adopt
such changes, and that the way to achieve compatibility is for
Maclisp/NIL not to make them in the first place.