[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: ALAN at MIT-MC, TLP at MIT-MC
- From: Robert W. Kerns <RWK at MIT-MC>
- Date: Sun, 18 Nov 79 14:51:00 GMT
- Cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-AI
- Original-date: 18 November 1979 09:51-EST
Date: 14 November 1979 03:45-EST
From: Alan Bawden <ALAN at MIT-MC>
To: BUG-LISPM at MIT-AI
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.