home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / bsd_srcs / usr.bin / lisp / lispnews / text0275.txt < prev    next >
Encoding:
Text File  |  1985-11-10  |  1.8 KB  |  36 lines
  1. The problems with a user-tailorable READ is one of the reasons why, over
  2. 12 years ago, we chose a format for MacLisp's FASL files that is
  3. somewhat akin to a position-independent list encoding.  (But in fact, it
  4. was primarily for speed that the READ-oriented option was abandoned).
  5.  
  6. However, there was still the need to introduce load-time evaluation, in
  7. order to create structures that can't be known even faintly at compile
  8. time; there is an "internal" marker, accessible to the MacLisp user as a
  9. global variable (named SQUID, I believe), so that the portions of a
  10. structure that need to be eval'd at load time could be marked.  E.g.
  11.     (FOO 3 '(SOME (DEEPLY NESTING (LIST IN #,LISPSYSTEMDATE))))
  12. and the #, signals a spot for load-time evaluation, even though the
  13. overall structure is essentally a QUOTE form.  
  14.  
  15. One needn't imagine that #, is the only client of this "internal" marker
  16. -- it provides the way to get all but the trivial datatypes into
  17. quotified structures; for example, I may have an input syntax for
  18. arrays, but still PRINT won't put them out (MacLisp PRINT won't, at
  19. least), and certainly not every conceivable datatype needs a special
  20. encoding for the FASL file format; merely a LIST, which is viewed as a
  21. general program by EVAL, is satisfactory to create any createable
  22. datatype instance.
  23.  
  24. Interlisp too has a loadtime evaluation construct, but it may only
  25. replace a QUOTE -- not some sub-piece of data underneath a QUOTE, such
  26. as indicated by the #, above.  A primary reason for this limitation is
  27. the similarity of Interlisp's and Franz's compiler output formats --
  28. basically an ascii string to which READ is applied.   MacLisp's loader
  29. is indeed quite more complex, but it results in a space savings for the
  30. FASL files and a considerable time savings when loading them.
  31.  
  32. -- Jon L White --
  33.  
  34.  
  35.  
  36.