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

  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!usc!cs.utexas.edu!sun-barr!olivea!apple!goofy!cambridge.apple.com!oddmund@idt.unit.no
  2. From: oddmund@idt.unit.no
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: RE: MCL size/distribution (was: MCL support for MOP)
  5. Message-ID: <199301101618.AA10128@sigyn.idt.unit.no>
  6. Date: 10 Jan 93 16:18:38 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 55
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11.  
  12. >We'll probably be
  13. >looking into a few ways to reduce the size of MCL (though probably
  14. >not for 2.1). 
  15.  
  16. >1) A tree shaker to automagically remove parts of MCL that are
  17. >   not used by your application.
  18.  
  19. A tree shaker would be nice, if one could conveniently declare a list of 
  20. functions etc. which might be used and therefore should not be removed.
  21.  
  22. >2) Make the development environment be optional, or distribute 2
  23. >   MCL applications: with & without development environment. Maybe
  24. >   even a third application that has just Common Lisp with no
  25. >   application framework.
  26.  
  27. The issue of alternative distribution forms is important. It involves not only 
  28. the size of what may be redistributed to end users of apps created in MCL, but 
  29. also the functionality of those apps. Obviously, Apple needs to prevent people 
  30. from "reselling" MCL, and that is the reason why the compiler must be excised 
  31. before redistribution. I believe other ways of reducing the value of what may 
  32. be redistributed should be considered. Removal of the development environment 
  33. is an obvious choice. 
  34.  
  35. This would make MCL extremely attractive for writing compilers of special 
  36. purpose languages, and for writing systems which contain such special purpose 
  37. languages. If necessary, a small fee (<<$500) could be charged for 
  38. redistribution with compiler but without development environment.
  39.  
  40. I believe that AppleScript will make programming languages a much more 
  41. important part of the Macintosh user interface. This will make it attractive to 
  42. provide many applications with end user programming languages (usually quite 
  43. similar to/extensions of AppleScript). Additionally, increased depth and 
  44. complexity of graphical user interfaces will make it more attractive to compile 
  45. plans created at runtime by user manipulation (as for example in ThingLab). 
  46. With a way to redistribute the compiler, MCL would be great for writing all 
  47. those future applications.
  48.  
  49. >3) One or more shared libraries for the different pieces of MCL.
  50. >   This will allow small MCL applications at the expense of some
  51. >   large inits.
  52.  
  53. This would be nice for developers with lots of homemade MCL applications on 
  54. their hard disk(s) (I'm working on becoming one of "them".). How about making 
  55. the development environment a big init? That might make tree shaking the rest 
  56. of each application easier as well. In such a scenario, developers could keep 
  57. exact end-user versions of apps on their hard disk. All end-user versions could 
  58. have the property that they call the development environment IF-AND-ONLY-IF(an 
  59. error occurs AND the development environment init is present). This would allow 
  60. convenient debugging without version confusion 
  61.  
  62.  
  63. Oddmund Mogedal
  64. Norwegian Institute of Technology
  65. oddmund@idt.unit.no
  66.