home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / editors / 3103 < prev    next >
Encoding:
Text File  |  1992-12-23  |  2.1 KB  |  44 lines
  1. Newsgroups: comp.editors
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!hpscit.sc.hp.com!cupnews0.cup.hp.com!news1.boi.hp.com!hp-pcd!hpcvusn!craig
  3. From: craig@cv.hp.com (Craig Durland)
  4. Subject: Re: Extension Languages
  5. Message-ID: <1992Dec23.213302.17326@hpcvusn.cv.hp.com>
  6. Sender: nobody@hpcvusn.cv.hp.com (Nobody - UID must be 99999)
  7. Nntp-Posting-Host: hpcvxcd.cv.hp.com
  8. Reply-To: craig@cv.hp.com
  9. Organization: Hewlett-Packard Company, Corvallis, Oregon USA
  10. X-Newsreader: TIN [version 1.1 PL7]
  11. References: <1992Dec16.092358.15791@u.washington.edu>
  12. Date: Wed, 23 Dec 1992 21:33:02 GMT
  13. Lines: 29
  14.  
  15. Tim Smith (tzs@carson.u.washington.edu) wrote:
  16. : davis@pacific.mps.ohio-state.edu  (John E. Davis) writes:
  17. : >The reason I chose a stack based language is easy:  The parsing stage is
  18. : >simple.  I did not want most of the executable devoted to the language.
  19. : 
  20. : I've been planning on using a stack based language for my editor, too.
  21. : This lets the basic editor (a C editing core, the interpreter, and a
  22. : few important functions written in the stack language) be small and
  23. : efficient.
  24. : 
  25. : Eventually, the plan is to also provide a C compiler that compiles
  26. : from C to the editor language, so that pepole who want to write their
  27. : editor programs in C can do so.  But this will be a separate program,
  28. : so that people who simply want a small and efficient editor don't have
  29. : to carry around the baggage of a C compiler or interpreter.
  30.  
  31. I've done this and it seems like a big win.  I didn't use C for the
  32. language-to-write-editor-extensions and I don't think you want to - C
  33. is too "low" level for writing extensions in (its great for writing the
  34. editor itself).  Extension writers shouldn't have to worry about memory
  35. allocation and all the other little details that C requires you to.
  36. This doesn't have to take lots of memory - I have garbage collection,
  37. recursion, lists, etc and the total editor size is < 150k (68k Unix).
  38. The extensions run slower than native C code but that doesn't seem to be
  39. much of a problem.
  40.  
  41.     Craig Durland       (503) 750-3354
  42.     Hewlett-Packard, 1000 NE Circle, Corvallis, OR 97330
  43.     craig@cv.hp.com
  44.