home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / forth / 2983 < prev    next >
Encoding:
Text File  |  1992-08-19  |  4.3 KB  |  94 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!kithrup!stanford.edu!ames!decwrl!csus.edu!netcom.com!xtifr
  3. From: xtifr@netcom.com (Chris Waters)
  4. Subject: Re: Still Trying to Decide about the Standard
  5. Message-ID: <vz!n=ym.xtifr@netcom.com>
  6. Date: Wed, 19 Aug 92 18:33:00 GMT
  7. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  8. References: <3956.UUL1.3#5129@willett.pgh.pa.us> <1992Aug19.125915.14313@mintaka.lcs.mit.edu>
  9. Lines: 83
  10.  
  11. In <1992Aug19.125915.14313@mintaka.lcs.mit.edu> mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:
  12.  
  13. >In article <3956.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
  14. >>Category 2,  Topic 2
  15. >>Message 116       Thu Aug 06, 1992
  16. >>E.RATHER [Elizabeth]         at 00:25 EDT
  17. >> 
  18. >>Re the recently quoted: 
  19. >> My own view is that a standard should solidify,
  20. >>clarify, extract,
  21. >> and document existing practice. The problem is in identifying "existing
  22. >>practice."  Does it mean:
  23. >>   (a) Stuff previously standardized (remember, it's been 10 years since FORTH-
  24. >>83)?
  25. >    It may have been a decade years since the 1983 standard was published, 
  26. >but we didn't get a good write-up out of that process. I've seen several 
  27. >people say that the '83 standard has major mistakes in it and that it
  28. >can't be implemented. So the most important thing in my mind is to document
  29. >what Forth was like 10 or 15 years ago in a clear consistant way.
  30.  
  31. Huh?  10 or 15 years ago???  I have to heartily disagree!!  Who cares
  32. what stone age systems that ran on the 8080 were like?  Let's take a
  33. look at what Forth is like today!
  34.  
  35. >The committee followed the example
  36. >of many other standards committees in writing hard to read documentation
  37. >that is supposed to be aimed at experts in the field. It should be for
  38. >those with technical backgrounds who never heard of Forth and want to know 
  39. >what is standard Forth practice.
  40.  
  41. Again, huh?  The purpose of the standard is to describe the language. 
  42. Not to describe practice, and not to stand as a tutorial!
  43.  
  44. >>   (c) Stuff that most implementors have done some way, but their approaches
  45. >>differ (in which case, how to find a synthesis or pick one?)?
  46. >   This is the most difficult area a committee has to deal with. If there
  47. >was a clear solution, then the implementors would be doing it the same
  48. >way.
  49.  
  50. Piffle!  Even with problems that have only one simple, clear solution,
  51. different vendors may still have used different NAMES for the same
  52. functions!  And picking on set of names may break a lot of existing code
  53. that uses a different set of names.  I think that the statement above is
  54. a gross oversimplification of the problem.
  55.  
  56. >Have they consulted with vendors and publishers of PD Forth
  57. >systems who cannot attend meetings of the committee or who have not sent
  58. >in proposals? 
  59.  
  60. Gawd, I sure hope not, considering how thoroughly lame most of the PD
  61. systems I've seen have been!  :-)
  62.  
  63. >>   (d) Stuff that <n> implementors do (in which case, what is <n>? And, as in
  64. >>(c), how to resolve different approaches to the same problem?)?
  65. >    Don't forget that the negative of this statement also deserves
  66. >consideration. Many implementors might deliberately leave out stuff
  67. >because they don't want it.
  68.  
  69. And they can continue to do so.  Only the CORE wordset is required by
  70. the standard to be present in any given implementation.
  71.  
  72. > Forth was created by selecting a particular
  73. >combination of programming methods that worked together. Adding to this
  74. >does not make a better system. Anything that is missing from a particular
  75. >version of Forth can be added by the user.  It doesn't have to be done
  76. >in a standard way. What we do have to standardize is the ability to 
  77. >add what is needed, not create a list of all commonly used programming
  78. >ideas.
  79.  
  80. Yeah, and for that matter, why bother to standardise words like `+'? 
  81. After all, the user can define it for himself!  It doesn't have to be
  82. done in a standard way.  And we all know that reinventing the wheel over
  83. and over and over again is *much* more important than getting any real
  84. work done.  The requirement to reinvent wheels, rather than
  85. concentrating on the task at hand is why Forth enjoys such incredible
  86. popularity in the mainstream computing world today!
  87.  
  88. Sheesh!
  89.  
  90. I don't even know why I bother.
  91. -- 
  92. Chris Waters    | the insane don't | NOBODY for President!
  93. xtifr@netcom.COM| need disclaimers | Because Nobody's perfect!!
  94.