[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
assq compatibility with Maclisp
- To: JCMA at MIT-AI, BUG-lisp at MIT-MC
- Subject: assq compatibility with Maclisp
- From: Glenn S. Burke <GSB at MIT-ML>
- Date: Sun, 11 Apr 82 21:37:00 GMT
- Cc: BUG-LISPM at MIT-AI
- Original-date: 11 April 1982 16:37-EST
Date: Saturday, 10 April 1982, 06:04-EST
Why do assq and assoc have to be incompatible with maclisp? That is,
why aren't assoc-careful and assq-careful the defaults?
It happens that Maclisp does not actually do assq-carefully, at least
not deliberately. It simply fails to check, and so can be fooled.
---- [transition to bug-lisp report] ----
uh oh... Even though i "knew" what maclisp was doing, i figured that
i would test it to see. The little cretin does assq-carefully in
(*RSET T) mode, and doesn't in (*RSET NIL) mode. What this means is
that the following happens in (*rset nil)
(assq nil '(0)) => 0
and in (*rset t) it yields NIL. The reason for this is that the CAR of
the fixnum 0 gives NIL. Similarly one can create other fixnums (and flonums)
which will fool assq for any other object.
So much for features. This sounds like a totally useless, misleading,
and inconsistent Maclisp feature. It is a waste of the address space
which someone has been trying hard to conserve. If it is going to check,
it should bitch, it shouldn't conditionally do the wrong thing.