home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / bsd_srcs / usr.bin / lisp / lispnews / text0232.txt < prev    next >
Encoding:
Text File  |  1985-11-10  |  2.3 KB  |  66 lines
  1. Versions: Franz 38.91, Liszt 8.39, and probably most others.
  2.  
  3. Description:
  4.     The atom predicate operates inconsistently between compiled and
  5.     interpreted code when passed a vector or vectori.
  6.  
  7. Repeat-by:
  8.     Create and compile a file containing the following definition:
  9.         (defun atum(x) (atom x))
  10.     After loading it into the interpreter the following results can
  11.     be obtained:
  12.         (setq v (vector 1 2 3))
  13.         (atom v)        ===> t
  14.         (atum v)        ===> nil
  15.  
  16. Discussion:
  17.     According to the manual, atom returns "t iff g_arg is not a list or
  18.     hunk object."  By this definition, the interpreter is correct and the
  19.     compiler incorrect.  However, one can make a strong argument that
  20.     vectors, analogously to hunks, should not be considered atoms.
  21.     Therefore, the both the documentation and interpreter should be
  22.     changed.  (It is doubtful very much existing code depends on this.)
  23.  
  24. Suggested fix:
  25.     Change the definition of atom section 2 of the manual to read:
  26.         "t iff g_arg is not a list, hunk, vector, or vectori object."
  27.     Add the following definition to franz/h/global.h, after the existing
  28.     definition of HUNKP:
  29.         #define HUNKORVECP(a1)    ((TYPE(a1) >= 11) & (TYPE(a1) <= 19))
  30.     Change the definition of Latom in franz/lam1.c:
  31.         lispval
  32.         Latom()
  33.         {
  34.             register struct argent *lb = lbot;
  35.             chkarg(1,"atom");
  36.     ==>        if(TYPE(lb->val)==DTPR || (HUNKORVECP(lb->val)))
  37.                 return(nil);
  38.             else
  39.                 return(tatom);
  40.         }
  41.  
  42. Alternative suggested fix:
  43.     If franz-composers really feel that atom ought to treat hunks
  44.     and vectors differently (sigh?), then fix the compiler instead
  45.     of the interpreter and documentation.  The most important thing
  46.     is that interpreted and compiler do the same thing!
  47.     In liszt/funa.l:cc-atom, add 1_18 and 1_19 to the definition
  48.     of the mask constant.
  49.  
  50. Random (constructive) flame:
  51.     The interpreter definition above has to lookup the type of its
  52.     argument expensively in the typetable *three* times, to wit:
  53.         #define ATOX(a1)    ((((int)(a1)) - OFFSET) >> 9)
  54.         #define    TYPE(a1)    ((typetable+1)[ATOX(a1)])
  55.     While compiled code is admirably streamlined, the interpreter
  56.     could be made significantly faster here and elsewhere if TYPE
  57.     were evaluated only once and held for examination in a
  58.     temporary.  This would require a bunch more type predicate
  59.     DEFINEs operating on TYPE values instead of object addresses.
  60.  
  61. Steve Haflich
  62. smh%mit-ems@mit-mc
  63. {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh
  64.  
  65.  
  66.