home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3767 < prev    next >
Encoding:
Text File  |  1993-01-05  |  2.4 KB  |  48 lines

  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!paladin.american.edu!europa.asd.contel.com!emory!wupost!csus.edu!netcom.com!jimlynch
  3. From: jimlynch@netcom.com (Jim Lynch)
  4. Subject: Re: Forth Standard Debate
  5. Message-ID: <1993Jan5.103140.15458@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1i7flnINN9or@life.ai.mit.edu> <1993Jan4.234621.12186@news.uakron.edu>
  8. Date: Tue, 5 Jan 1993 10:31:40 GMT
  9. Lines: 37
  10.  
  11. In article <1993Jan4.234621.12186@news.uakron.edu> r3btg@vax1.cc.uakron.edu (Ben T Galehouse) writes:
  12. >It is quite amusing to listen to everyone argue.  Here is what I think.
  13. >There should be standards.  This isn't difficult to justify.  People
  14. >need to know that there is _a_ forth standard that everybody uses.  This
  15. >makes learning forth much easier.  Code portability is also a factor.
  16. >
  17. >However, for forth to keep it's spirit, must also be deviation from the
  18. >standard.  Often, a machine's architechture dictates the fastest or the
  19. >shortest way to do something.  Also, especialy in embedded applications,
  20. >no one application will need all the commands often included with forth.
  21. >This sort of deviation from the standard must be accepted and even
  22. >supported, no matter how badly a person advocates that standard.
  23. >
  24. >One of the most important characteristics of forth is it's size and
  25. >consision.  To this end, I suggest a group of malleable standards.
  26. >There should be a very short basic description of forth.  On top of
  27. >that, there should be a description of how forth should be implimented
  28. >on 16-bit machines and on 32-bit machines (size of stack? if the stack
  29. >is 32 bits, how to work with 16-bit arrays?).  If somebody wants to
  30. >devise a graphic standard (variable names that contain the screen size?)
  31. >that is also fine.  Not all 32-bit machines have graphic interfaces.
  32. >Not all people want floating point support.  The standard should be
  33. >modular.  There should be a 16-bit standard.  There should be a 32-bit
  34. >standard.  There should be a floating point standard.  (why not add a
  35. >floating point stack) 
  36. >
  37. >Most importantly, however, all source code should always be provided,
  38. >and everything should be no larger than necessary.  This is the most
  39. >universal forth standard  --- the programer should understand the
  40. >compiler and everything about it.
  41. >-- 
  42. >r3btg@vax1.cc.uakron.edu          15764 Galehouse Rd.
  43. >Ben Galehouse              Doylestown, OH, 44230
  44. >(216) 658-3556           
  45.  
  46. Contact the Forth Interest Group.
  47.