home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / mcl / 1953 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.0 KB
  1. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!ames!olivea!apple!cambridge.apple.com!bill@cambridge.apple.com
  2. From: bill@cambridge.apple.com (Bill St. Clair)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: MCL support for MOP
  5. Message-ID: <9301082050.AA28536@cambridge.apple.com>
  6. Date: 8 Jan 93 21:56:58 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 66
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11. >bill@cambridge.apple.com (Bill St. Clair) writes:
  12. >
  13. >> Adding more MOP support to MCL is on my list of
  14. >> things to do, but it's not very near the top of the list so I'm not
  15. >> likely to do it soon.
  16. >
  17. >I wonder how high the need for MOP support is on the list of typical
  18. >MCL users. Some users are worried about the lack of MCL/MOP features.
  19. >Others, however, (including me) don't really use MOP and, therefore,
  20. >are worried about making trade offs regarding performance and/or
  21. >memory.
  22. >
  23. >Questions:
  24. >
  25. >- what impacts would a full MOP implementation have to MCL in terms of
  26. >  performance or memory?
  27. >  
  28. >- could a full MOP implementation be packaged into a separate module 
  29. >  (sort of like PCL minus MCL)
  30.  
  31. Top of my head estimates follow. Take with a grain of salt.
  32.  
  33. I doubt that a MOP implementation will require much extra space.
  34. MCL's entire CLOS implementation is only about 270K of source code
  35. which compiles to less than 100K of fasl files (fasl file size is
  36. usually close to in-memory size) The MOP will probably add another
  37. 50 to 100K to the source, so it's likely to increase MCL's in-memory
  38. size by 20 to 50K. Some of this will be swappable, so it will only
  39. take up disk space if you don't use it.
  40.  
  41. >
  42. >One of the many nice things about MCL is its size compared to other
  43. >Common Lisp implementations. It allows developers to create
  44. >applications able to run on low-end machines. However, If more and
  45. >more functionality is creeping into MCL (maybe partly due to the
  46. >ANSIfication of the Common Lisp clean up process) I wonder how much
  47. >longer this is going to be true.
  48.  
  49. There are a couple of reasons that MCL 2.0 is bigger than 1.3.
  50. The pretty printer and inspector are included in 2.0, they were
  51. provided as fasl files in 1.3. 2.0's CLOS generic functions cost a
  52. little more space than 1.3's Object Lisp obfuns. We'll probably be
  53. looking into a few ways to reduce the size of MCL (though probably
  54. not for 2.1). Some ideas are:
  55.  
  56. 1) A tree shaker to automagically remove parts of MCL that are
  57.    not used by your application.
  58.  
  59. 2) Make the development environment be optional, or distribute 2
  60.    MCL applications: with & without development environment. Maybe
  61.    even a third application that has just Common Lisp with no
  62.    application framework.
  63.  
  64. 3) One or more shared libraries for the different pieces of MCL.
  65.    This will allow small MCL applications at the expense of some
  66.    large inits.
  67.  
  68. Feedback please. Do you need these facilities? Other ideas?
  69. The MCL development team has decided that MCL's size is not the
  70. most important thing we have to work on right now, but it's
  71. still important to us.
  72.  
  73.  
  74. -----
  75. Bill St. Clair
  76. bill@cambridge.apple.com
  77.