home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / forth / 3091 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.5 KB
  1. Path: sparky!uunet!gatech!pitt!willett!dwp
  2. From: dwp@willett.pgh.pa.us (Doug Philips)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Free Forth
  5. Message-ID: <4046.UUL1.3#5129@willett.pgh.pa.us>
  6. Date: 8 Sep 92 16:52:07 GMT
  7. Organization: EIEI-U
  8. Lines: 48
  9.  
  10. In article <1992Sep5.151245.18215@mintaka.lcs.mit.edu>
  11.     mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:
  12.  
  13. +In article <BtCvML.Lzu@starnine.com> mikeh@starnine.com (Mike Haas) writes:
  14. +>
  15. +>The trend is more & more memory in the machine, so what do I care
  16. +>if a Forth takes up 100k or 500k if I have Megs to work with?
  17. +>
  18.  
  19. +   A small Forth fits in a human mind better than a big one. You can
  20. +do more with a system that you understand very well than you can with
  21. +a big system that you don't understand. Forth works very well in a
  22. +small space since it uses a few good ideas put together in a clever
  23. +way. It is a much better way to do things than filling up all
  24. +available memory with more code than a single person can comprehend.
  25.  
  26. I almost agree with that sentiment.  There is a difference between size and
  27. (in)comprehensibility though.  I think the real issue is organization.  Is a
  28. Forth whose WORDS prints 70 words easier to understand than a Forth whose
  29. WORDS prints 300+?  From that statistic alone an answer is impossible.
  30. WORDS is not a structured/organized way to look at the dictionar(y,ies).
  31.  
  32. I do not want a tiny Forth that I can understand, but which I have to
  33. completely reimplement the wheel in order to get host file system access,
  34. floating point support, string package support, etc.
  35.  
  36. I do not want a humongous Forth that has everything including the kitchen
  37. sink thrown in, all in one big incomprehensible glop.
  38.  
  39. I do want a Forth that is cleanly implemented, can meta compile itself with
  40. minimal fuss, and has loadable (either source or precompiled with source
  41. available) packages for common functionality.o
  42.  
  43. I do want Forth implementations that conform to and present a portable
  44. interface to common functionality, so that I can convert a Forth program
  45. written on a Unix Box to a PC, MacIntosh, Amiga, etc., with minimal (if any)
  46. headaches.
  47.  
  48. I do want Forth implementations that permit me to control resource usage
  49. through the control of packaged "add ons".  The "Packaged Add Ons" should
  50. have documented interfaces, so that if one "add on" requires the use of
  51. another "add on", I have the liberty (but not requirement!) to provide
  52. my own alternative and not have to worry about undocumented side effecting
  53. communication channels, etc.
  54.  
  55. -Doug
  56. ---
  57. Preferred:  dwp@willett.pgh.pa.us    Ok:  {pitt,sei}!willett!dwp
  58.