home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / forth / 3017 < prev    next >
Encoding:
Text File  |  1992-08-22  |  2.1 KB  |  49 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!decwrl!csus.edu!netcom.com!xtifr
  3. From: xtifr@netcom.com (Chris Waters)
  4. Subject: Re: ANS TC Magnet for ROMability
  5. Message-ID: <c6+nx!-.xtifr@netcom.com>
  6. Date: Sat, 22 Aug 92 22:18:41 GMT
  7. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  8. References: <4002.UUL1.3#5129@willett.pgh.pa.us>
  9. Lines: 38
  10.  
  11. In <4002.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
  12.  
  13. >Category 10,  Topic 22
  14. >Message 78        Fri Aug 21, 1992
  15. >B.RODRIGUEZ2 [Brad]          at 22:52 EDT
  16. > 
  17. >                 ANSI X3J14 FORTH TECHNICAL PROPOSAL
  18. >                     (X3J14 dpANS-3, March 1992)
  19.  
  20. >TITLE:  New category: ANS Forth Translator
  21.  
  22. Oops, in my previous post, I misinterpreted what Brad was proposing,
  23. because I hadn't read his subsequent posts.  I like this idea, but my
  24. gut reaction is: not now.  The standard, *as it sits* is already
  25. controversial, and adding a whole new idea, like a "standard translator"
  26. will simply open up whole new areas of complexity and controversy.
  27.  
  28. >          A programming language processor conforms to this
  29. >          Standard and may be labeled an 'ANS Forth Translator'
  30. >          if it is capable of compiling, but not executing, in
  31.  
  32. This section is what I have the most problem with.  EVERY cross-compiler
  33. I've seen DOES allow you to define and execute words in the host system.
  34. Better (as I mentioned in my previous post) to codify and standardize
  35. the types of things that are done in cross-compilers, and create a
  36. standard that will WORK for both cross-compilers and standard Forth
  37. systems.  Which would be, I suspect, a MAJOR undertaking, which might
  38. delay the completion of the standard for years.
  39.  
  40. Brad's proposal here seems FAR too limiting--better to have no standards
  41. in this area than to have a bad one.
  42.  
  43. In another post, he did mention some possible clarifications to the
  44. standard about the ability to execute newly defined words and such.  That
  45. proposal does seem reasonable.
  46. -- 
  47. Chris Waters    | the insane don't | NOBODY for President!
  48. xtifr@netcom.COM| need disclaimers | Because Nobody's perfect!!
  49.