Re: MAKE-LIST -- Compromise? Please, not that way ...

[Kent M. Pitman <KMP 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.