(atom VECTOR): franz vs liszt

[@mit-mc:smh@mit-ems]

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