home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / mcl / 1987 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  2.1 KB

  1. Path: sparky!uunet!world!paradigm!lph
  2. From: lph@paradigm.com
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Exes and Re: MCL size/distribution
  5. Message-ID: <13697@paradigm.com>
  6. Date: 12 Jan 93 01:59:42 GMT
  7. Organization: Paradigm Associates Inc, Cambridge MA
  8. Lines: 39
  9.  
  10. From the standpoint of a developer of a large software system for
  11. use under a variety of common lisps on various hardware platforms:
  12.  
  13. The tree-shaker approach falls a little short for programs that
  14. compute a function to be APPLY'ed or FUNCALL'ed unless you supply
  15. a mechanism for a training run or can specify a list of functions
  16. to include.
  17.  
  18. As far as reducing the amount of CL that must be present
  19. in an executable image, I personally favor the approach taken in
  20. DEC's VAX-Lisp 2.2 (modified to be less favorable in later releases.)
  21. There you select a set of relatively orthogonal extensions beyond
  22. basic functionality and can eliminate those desired, such as the
  23. compiler, debugger, editor interface, read-eval-print loop, window
  24. system graphics, and etc. [a certain subset is mandatorily excluded
  25. for execute-only systems that you can distribute without a license,
  26. and the amount that must be excluded was increased in subsequent
  27. releases, which is less favorable to developers.] If this could be
  28. extended further to enable me to exclude certain CL functions that
  29. I never call (as long as they aren't called in functions that I
  30. retain) I would be able to reduce the size of an executable further.
  31.  
  32. Can the building of an executable image be made more intelligent?
  33. So that functions that call each other get on the same set of
  34. pages to reduce paging/swapping? Can the garbage collector place
  35. lists more contiguously in memory for the same purpose?
  36.  
  37. I am very impressed with MACL in general, since it executes very
  38. favorably and in a very modest amount of space compared with
  39. other CL implementations on other machines, though it does not
  40. carry out much of the open-coding that is characteristic of
  41. other lisps on other hardware.
  42.  
  43. Leo Harten
  44. Paradigm Associates, Inc.
  45. 29 Putnam Avenue, Suite 6
  46. Cambridge, MA 02139/USA
  47. +1(617)492-6079
  48. LPH@PARADIGM.COM
  49.