home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / programm / 15526 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.9 KB
  1. Path: sparky!uunet!decwrl!contessa!mwm
  2. From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
  3. Subject: Building a LISP (WAS: LISP - Don't use it.)
  4. Newsgroups: comp.sys.amiga.programmer
  5. Distribution: world
  6. References: <mwm.2k43@contessa.palo-alto.ca.us> <BxDB5t.EC9@fc.hp.com>
  7. X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
  8. Keywords: 
  9. Summary: 
  10. Message-ID: <mwm.2kd1@contessa.palo-alto.ca.us>
  11. Date: 7 Nov 92 20:20:55 PST
  12. Organization: Missionaria Phonibalonica
  13. Lines: 50
  14.  
  15. In <BxDB5t.EC9@fc.hp.com>, koren@fc.hp.com (Steve Koren) wrote:
  16. > Mike Meyer (mwm@contessa.palo-alto.ca.us) wrote:
  17. > 
  18. > > The only thing that makes
  19. > > LISP-like languages "quick&easy to interpret" is that the syntax is
  20. > > trivial. Almost everything else about the language makes it HARD to
  21. > > implement. That's because the language is designed to be elegant and
  22. > > powerful, as opposed to easy to implement or easy to use.
  23. > 
  24. > Ok, I'll bite.  Why do you consider LISP as hard to implement?  I've
  25. > written a LISP interpreter to test some namespace caching techniques
  26. > I was working on.  It is fairly complete, and faster than GNU lisp
  27. > or X-lisp 2.0 by quite a bit in many cases.  I've also written both C
  28. > and Pascal compilers and a Unix ksh-like script language interpreter.
  29.  
  30. Depends on what you mean by "fairly complete." If you provided a
  31. C/Pascal level of functionality, then you're right. About all that's
  32. left is the garbage collector, which is still simpler than a C or
  33. Pascal parser. However, if you throw in the things I expect to find in
  34. a LISP (lexical binding, closures, continuations, and backquotes to
  35. name a few) then it becomes more difficult. But those are the features
  36. designed to make LISP elegant and powerful, etc.
  37.  
  38. > In fact,
  39. > once you get the parser done (which is very easy) LISP becomes almost
  40. > trivial to write if you use good object oriented programming techniques,
  41.  
  42. That's sort of how I feel about conventional languages, only I'd say
  43. "good structured programming technics". That's because the primitives
  44. in most of them are, well, primitive. I don't have your compiler
  45. experience, though; except for coursework, I've built "little
  46. languages" that I can design to orthogonal and straightforward.
  47. Building them as LISP extensions means I even get parsers for free.
  48.  
  49. > (BTW, I'm not disagreeing; just curious about why you think that.
  50. > Everybody has their own concept of what is hard and what is easy, and
  51. > you can't say one is "right" or "wrong", of course.  I consider
  52. > hardware design almost impossibly hard, but its trival for lots of
  53. > folks :-) )
  54.  
  55. I think doing a "modern" LISP is hard. That means you've got all/most
  56. of the things I mentioned. Doing an "older" lisp - dynamic binding (a
  57. bug), ignoring the funarg problem, and as an interpreter is pretty
  58. trivial.  That's why they're used for "simple" macro/script languages.
  59.  
  60. BTW, XLISP is notoriously slow, and ELISP wasn't designed for speed.
  61. Almost any of the Amiga Schemes (including XScheme) will be faster.
  62. ARexx falls in the middle.
  63.  
  64.     <mike
  65.