home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / bsd_srcs / usr.bin / lisp / lispnews / text0029.txt < prev    next >
Encoding:
Text File  |  1985-11-10  |  3.8 KB  |  95 lines
  1.   I sent the maryland people the flavors.usage file from mit so that they
  2. could compare their implementation with mit's.   What follows is their
  3. analysis.   Some of the differences between the two versions is due to
  4. different schemes for getting around the fact that franz didn't have a form
  5. of closure.   RZ has indicated that now that franz has fclosures, it may be
  6. possible to use more of the 'official' lisp machine flavor code.  fclosures
  7. will probably affect the maryland implementation too:
  8. Date:     22 Oct 82 15:39:18 EDT  (Fri)
  9. From:     Liz Allen <liz.umcp-cs@UDel-Relay>
  10. Subject:  flavors
  11. To:       jkf at Ucb-C70
  12. Via:  UMCP-CS; 23 Oct 82 9:09-EDT
  13.  
  14. Wow, implementing closure in one day is amazing.  We had thought
  15. about writing some kind of closure...  We've been discussing how
  16. having closures would affect our code.  It might make it easier to
  17. read and modify, but it might be less efficient.  Can you tell us
  18. how your implementation works and what it looks like to a user?
  19.  
  20. About the MIT implementation.  Ours is probably better in a couple
  21. of respects but probably loses a couple of places, too.  Pros:
  22.  
  23.     1.  With ours, there is no need to discard instances when
  24.     redefining a flavor.  The only time this would be necessary
  25.     is if the instance variables change which rarely happens
  26.     since methods change much more often than the instance
  27.     variables.  Without a structure editor, you tend to reload the
  28.     file containing flavors in order to change a method.
  29.  
  30.     2.  We can compile files with flavors (he didn't say if you
  31.     can compile MIT's Franz flavors) and when they are compiled
  32.     they run *fast*.  Most of the overhead occurs at combine
  33.     time and compiled flavors shouldn't have to be recombined.
  34.  
  35.     3.  We use hunks to store instance variables (actually, an
  36.     instance is a hunk whose cxr 0 is the name of the flavor and
  37.     whose cxr n (> 0) are the values of instance variables).  We
  38.     pay a price at combine time since instance variable references
  39.     in method code are replaced with cxr and rplacx calls (but MIT
  40.     pays the same price in putting hash calls in the methods), but
  41.     we win over MIT since the cxr calls are much faster than the
  42.     hash table calls.  We do have to have "ghost" methods which
  43.     are copies of methods containing different cxr calls when the
  44.     referenced variables of a method don't align in flavors
  45.     which inherit the method.  This, however, happens only
  46.     rarely.
  47.  
  48.     4.  We handle getting and setting instance variables better
  49.     than the MIT implementation -- we don't need to send a message
  50.     and the syntax is much better.  We recently added the
  51.     functions << and >> which get and set instance variables, eg:
  52.  
  53.         (<< foo 'instance-var)
  54.     and
  55.         (>> foo 'instance-var 'value)
  56.  
  57.     where foo is a flavor instance.
  58.  
  59.     5.  Our describe function has a hook which (if the variable
  60.     *debugging-flavors* is set to non-nil) allows the user to
  61.     follow pointers to any instances referenced in the describe.
  62.     This is done by assigning to a variable (made from its unique
  63.     id) the value of the instance.
  64.  
  65. Cons:
  66.  
  67.     1.  They implement more things from Lisp Machine flavors
  68.     (like wrappers/whoppers, init-keywords), but we really haven't
  69.     found the need for them.  We implement less closely to LM
  70.     flavors, but in a way that's better suited to Franz Lisp.
  71.  
  72.     2.  We didn't implement the method table as a hash table, but
  73.     there's no reason why we couldn't.
  74.  
  75.     3.  Things we don't have, but could easily implement include:
  76.     describe-method, defun-method/declare-flavor-instance-variables,
  77.     and storing flavor information in hunks instead of on the
  78.     property lists.
  79.  
  80.     4.  We don't handle method types like :and and :or.  We just
  81.     have primary/untyped methods and :before and :after daemons.
  82.  
  83. We have people reading our documentation.  After we get some feedback
  84. from them, we'll send the tape and docs to you.  That should be early
  85. next week.
  86.  
  87.                 -Liz Allen and Randy Trigg
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.