home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / mcl / 1957 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  1.7 KB
  1. Path: sparky!uunet!olivea!apple!cambridge.apple.com!UK0392@AppleLink.Apple.COM
  2. From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re2: MCL support for MOP
  5. Message-ID: <726535844.9412454@AppleLink.Apple.COM>
  6. Date: 8 Jan 93 23:16:00 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 29
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11. Bill & friends,
  12.  
  13. >We'll probably be looking into a few ways to reduce the size of MCL (though
  14. >probably not for 2.1).
  15.  
  16. 1) A tree shaker - could be neat, but sounds like a lot of effort given the
  17. sneaky ways that fruit can be accessed.
  18.  
  19. 2) Make the development environment be optional - I have used languages like
  20. ProIcon which come with a 'runtime' version for distribution, and must admit
  21. that I rather like them.  It also gives the development team scope for
  22. additional optimisations within the runtime.  It gets my vote.
  23.  
  24. 3) One or more shared libraries - technologically attractive, but probably the
  25. clumsiest when it comes to distributing apps to ordinary users.  We have enough
  26. trouble with the INIT required for the dongles that we have to use!
  27.  
  28. Overriding these, to me at least, is the eventual availability of Dylan.  If
  29. the policy stated in the book is set - that MCL will remain a full CL
  30. implementation - and a lean, mean commercially-viable Dylan is released for the
  31. Mac, then I for one would be very happy to use MCL for its strengths, and Dylan
  32. for commercial work (sometimes exploring and doing initial development in MCL,
  33. and finishing off in Dylan).  I think that could take a lot of emphasis off
  34. MCL's size and memory requirements, which would fit with
  35. >though probably not for 2.1
  36. too?
  37.  
  38. Howard.
  39.  
  40.