[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MAKE-LIST -- Compromise? Please, not that way ...
- To: JONL at MIT-MC
- Subject: Re: MAKE-LIST -- Compromise? Please, not that way ...
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Mon ,3 Nov 80 13:10:00 EDT
- Cc: LISP-FORUM at MIT-MC
Date: 3 November 1980 06:56-EST
From: Jon L White <JONL at MIT-MC>
Date: 3 November 1980 01:52-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Yes, the Lisp Machine MAKE-LIST should originally have been defined to
take the area secondly as an optional argument. What you make Maclisp
do depends more on whether you are concerned with compatibility, or the
right thing. Both the NIL and Lisp Machine groups seem extremely
reluctant to put up with language deficiencies, even minor ones, simply
to be compatible with the other.
In this case, the MAKE-LIST one, it seems highly unlikely that open-coding
is important -- why not let it be a subr which "sniffs" at its two
arguments and reverses them if the one which should be an "area pointer"
is a "fixnum" and vice-verse? We could then say
1) MAKE-LIST has the "right" definition
2) but practical implementations have a kludge which is "tolerant" of
a somewhat lazy programmer (and still is 99.99% fail safe)
That's not the `right' definition. That's lossage. It smells of DWIM.
I think it's far more important for these languages to have regular
definitions than for them to be precisely compatible. If they have regular
definitions, they can at least be mechanically translated back and forth.
The sort of kludge suggested here is ugly and un-called for. Alan's
suggestion of (MAKE-LIST #Q area fixnum) is far cleaner ... which doesn't
say much. You're talking about the design of two languages which attempt
to *correct* some of the kludgeyness in their predecessors (Maclisp) ...
I think this is a truly bad idea.
Why is it that you can't just change the definition in NIL and recompile
the code. I can write you a Teco macro that will do it query-replace-style
for a buffer... If you have a tags file, I can make it map the whole file.
I think the compromises DLW was suggesting involved actually
having one side or the other actually concede the point and change their
definition. NIL has little code depending on it right now -- far less than
LispM. The NIL source is probably the only body of code that is relying
on a particular definition and I think it would be easier for us to change
NIL than for LispM to change all of their code and their users' code.
If compatibility is really desired, I think that's how it's to be achieved
in this case.