home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / mcl / 1951 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  1.5 KB
  1. Path: sparky!uunet!wupost!spool.mu.edu!olivea!apple!cambridge.apple.com!ralex@tigger.cs.colorado.edu
  2. From: ralex@tigger.cs.colorado.edu (Repenning Alexander)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: MCL support for MOP
  5. Message-ID: <199301080448.AA02879@tigger.cs.colorado.edu>
  6. Date: 8 Jan 93 04:48:41 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 29
  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. One of the many nice things about MCL is its size compared to other
  32. Common Lisp implementations. It allows developers to create
  33. applications able to run on low-end machines. However, If more and
  34. more functionality is creeping into MCL (maybe partly due to the
  35. ANSIfication of the Common Lisp clean up process) I wonder how much
  36. longer this is going to be true.
  37.  
  38.  
  39.    Alex Repenning
  40.