home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / mcl / 1985 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.6 KB
  1. Path: sparky!uunet!spool.mu.edu!olivea!apple!cambridge.apple.com!ph@netcom.com
  2. From: ph@netcom.com (Peter Hendrickson)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re2: MCL support for MOP
  5. Message-ID: <9301112257.AA16886@netcom.netcom.com>
  6. Date: 11 Jan 93 22:57:30 GMT
  7. References: miller@cs.rochester.edu's message of Mon, 11 Jan 93 15:57:09 -0500 <9301112057.AA08801@larynx.cs.rochester.edu>
  8. Sender: info-mcl-request@cambridge.apple.com
  9. Lines: 49
  10. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  11.  
  12.  
  13. > Brent Benson   writes...
  14. > I'm not convinced that it is hard to tree shake code that does not
  15. > contain calls to eval.  I would appreciate it if someone could tell me
  16.  
  17. Then Ben Hyde writes ...
  18. > More generally any interning can create symbols that can then have
  19. > symbol-function applied to them.  I.e. parsing user input can lead to
  20. > difficulties knowning what the domain over which intern can operate.
  21. > This is can be handled by disallowing intern, and find-symbol.  The
  22. > application writer must then implement his own find-symbol/intern if
  23. > he desires this functionality.
  24.  
  25. Bob Kerns says ...
  26. > In fact, in my coding style, I avoid symbol-function.  I tend
  27. > to write macros that define functions, and then store the function
  28. > itself in a data-structure, or write #'foo instead of 'foo.
  29.  
  30. > If you use symbol-function, who knows what you might end up
  31. > running?  ;=)
  32.  
  33. Then miller@cs.rochester.edu states...
  34. > On the flip side, I couldn't live without symbol-function. When I
  35. > incrementally redefine a function symbol in a file (e.g. defun of foo),
  36. > I don't want to go have to recompile every #' mention of the function, I
  37. > want the newest version always. Sure, it loses in the face of a macro,
  38. > but that's just another reason to try to avoid macros (or at least get
  39. > them right the first time :-).
  40.  
  41. How about a tree shaker that warns you that symbol-function or
  42. eval calls prevent it from shaking everything out? Then the
  43. developer can decide whether he or she wants a small application
  44. or symbol-function.
  45.  
  46. I'd be happy to gimp the functionality of Lisp from time to time
  47. if it meant I could have an application which fit onto a single
  48. diskette. I have not yet heard a convincing explanation of what
  49. makes this hard.
  50.  
  51. For simple or even moderately complex applications, I suspect the
  52. lavish amounts of disk space and memory consumed by MCL are mostly
  53. unused. (Please enlighten me if you know better.)
  54.  
  55. I like MCL and I think the people who have worked on it over the
  56. years have done a great job. But, I'd like it even more if I could
  57. confidently compete with C programmers using it.
  58.  
  59. Peter Hendrickson
  60. ph@netcom.com
  61.