[no subject]

[Robert W. Kerns <RWK at MIT-MC>]

cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-AI

    Date: 14 November 1979 03:45-EST
    From: Alan Bawden <ALAN at MIT-MC>
    To:   BUG-LISPM at MIT-AI
    cc:   BUG-LISP

        Date: 13 NOV 1979 0925-EST
        From: TLP at MIT-AI (Tomas Lozano-Perez)

        Why doesn't ASSOC in LISPM LISP just ignore atoms in the
        list argument (like MacLisp does) instead of barfing by
        trying to take CAAR of them?

    Is this really a feature of MacLisp? I can't seem to find
    this in the moonual or in LISP NEWS or in the new MacLisp
    manual.  It does behave this way on both ITS and Multics,
    but I would have reported it as a bug if I had found out
    about it on my own.  It really is a shame that the
    LispMachine is forced to continue such lossages.  Another
    example is the MacLisp definition of new-style DO in the
    case where the second "argument" is nil, it executes the
    body just once!  This one is documented at least, but it
    sure is random!
The DO feature is at least useful ...

Anyway, ASSOC happens to behave this way, because it lets you use
'((A . B) NIL (C . D)) and have the NIL entry ignored.  This
ends up carrying over to symbols because it uses (ATOM X) instead
of (NULL X).  Lose, lose.  I think MacLisp should be changed...
even the feature of ignoring null entries is kind of marginal.
It should just do a null-check, like ASSQ does.

TLP:  If you're using ASSQ in MacLisp, it will LOOK like it's working, but
will merely be taking the CAR of the symbol, which is unlikely to match
your argument.  It is merely randomness that this isn't also true of
ASSOC.  I.e. your code is bugous.