[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: HIC at MIT-MC, RWK at MIT-MC
- Subject: LAST
- From: RWK at MIT-MC (Robert W. Kerns)
- Date: Wed, 6 Sep 78 07:00:00 GMT
- Cc: (BUG LISP) at MIT-MC, CWH at MIT-MC
- Original-date: 6 SEP 1978 0300-EDT
Date: 5 SEP 1978 2340-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, CWH at MIT-MC
From: RWK at MIT-MC (Robert W. Kerns)
Your comment would be almost valid, except that LAST obviously isn't
just CDR'ing down the list checking for NIL. It is doing a LIST-P
on the CDR instead.
You are wrong. It is doing a NIL check (look at the damn code before
Twas faked out by it's coincidentally working since the CDR of an atom is
its (usually null) plist. Another example of randomness that this can cause!
After all, this isn't very expensive, a MOVEI, a LSH,
and a SKIPL will do it. I would muchly appreciate it if APPEND would
be changed to do likewise.
Compared to a JUMPN, a MOVEI, LSH, and SKIPL are quite expensive.
Aw c'mon. Yes, it doubles the loop size. It still probably all runs in the
cache (on KL's). I still wouldn't call it expensive for an interpreter
(There should also be a TYPEP before the loop,
so (LAST 3.3) wouldn't die).
I had this idea also, and I might implement it.
After all, the interpreter isn't supposed to
be fast, it's supposed to be suportive and not die on easy mistakes.
This is true...on the other hand, one does not want to make it unbearably slow.
Perhaps a *RSET check is in order...more thought is necessary.
I would go along with this....*RSET is for things like that.