[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(atom VECTOR): franz vs liszt
- To: franz-friends@Berkeley
- Subject: (atom VECTOR): franz vs liszt
- From: @mit-mc:smh@mit-ems
- Date: Fri, 10 Aug 84 20:06:48 GMT
- Original-date: 10 Aug 1984 16:06:48-EDT
Versions: Franz 38.91, Liszt 8.39, and probably most others.
Description:
The atom predicate operates inconsistently between compiled and
interpreted code when passed a vector or vectori.
Repeat-by:
Create and compile a file containing the following definition:
(defun atum(x) (atom x))
After loading it into the interpreter the following results can
be obtained:
(setq v (vector 1 2 3))
(atom v) ===> t
(atum v) ===> nil
Discussion:
According to the manual, atom returns "t iff g_arg is not a list or
hunk object." By this definition, the interpreter is correct and the
compiler incorrect. However, one can make a strong argument that
vectors, analogously to hunks, should not be considered atoms.
Therefore, the both the documentation and interpreter should be
changed. (It is doubtful very much existing code depends on this.)
Suggested fix:
Change the definition of atom section 2 of the manual to read:
"t iff g_arg is not a list, hunk, vector, or vectori object."
Add the following definition to franz/h/global.h, after the existing
definition of HUNKP:
#define HUNKORVECP(a1) ((TYPE(a1) >= 11) & (TYPE(a1) <= 19))
Change the definition of Latom in franz/lam1.c:
lispval
Latom()
{
register struct argent *lb = lbot;
chkarg(1,"atom");
==> if(TYPE(lb->val)==DTPR || (HUNKORVECP(lb->val)))
return(nil);
else
return(tatom);
}
Alternative suggested fix:
If franz-composers really feel that atom ought to treat hunks
and vectors differently (sigh?), then fix the compiler instead
of the interpreter and documentation. The most important thing
is that interpreted and compiler do the same thing!
In liszt/funa.l:cc-atom, add 1_18 and 1_19 to the definition
of the mask constant.
Random (constructive) flame:
The interpreter definition above has to lookup the type of its
argument expensively in the typetable *three* times, to wit:
#define ATOX(a1) ((((int)(a1)) - OFFSET) >> 9)
#define TYPE(a1) ((typetable+1)[ATOX(a1)])
While compiled code is admirably streamlined, the interpreter
could be made significantly faster here and elsewhere if TYPE
were evaluated only once and held for examination in a
temporary. This would require a bunch more type predicate
DEFINEs operating on TYPE values instead of object addresses.
Steve Haflich
smh%mit-ems@mit-mc
{decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh