home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / forth / 3016 < prev    next >
Encoding:
Text File  |  1992-08-22  |  3.1 KB  |  85 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: <95+n5g+.xtifr@netcom.com>
  6. Date: Sat, 22 Aug 92 22:08:35 GMT
  7. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  8. References: <4000.UUL1.3#5129@willett.pgh.pa.us>
  9. Lines: 74
  10.  
  11. In <4000.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 76        Fri Aug 21, 1992
  15. >B.RODRIGUEZ2 [Brad]          at 22:45 EDT
  16.  
  17. Brad asks about the possibility that a cross-compiler could be an ANSI
  18. standard system (as opposed to merely being a standard program).  The
  19. answer, as I see it is: no way!!
  20.  
  21. It might be a good idea *at some point* to come up with a way to define
  22. "standard cross-compilable programs", but Forth is, and always has been,
  23. an interpretive language.  Cross-compilers remove the interactive nature
  24. (specifically, the ability to execute newly created definitions).
  25.  
  26. There's one exception to my "no way" comment above: if the
  27. cross-compiler can, somehow, execute a newly created definition out of
  28. the target system.  This is far beyond the capabilities of most cross
  29. compilers I have seen, but I suppose it might be possible in some cases.
  30.  
  31. >QUESTIONS:  Please answer the following:
  32.  
  33. [I've only answered a subset of these]
  34.  
  35. >  6. To what extent must newly-defined Forth words, comprising a
  36. >     Standard Program, be executable interpretively in a Standard
  37. >     System?
  38.  
  39. 100%
  40.  
  41. >  7. Which of the following are valid Standard Programs?
  42.  
  43. >     a)   4 5 + .
  44.  
  45. >     b)   : TEST  4 5 + . ;
  46.  
  47. >     c)   : TEST  4 5 + . ;  TEST
  48.  
  49. >     d)   4 CONSTANT FOUR   FOUR 5 + .
  50.  
  51. >     e)   : SQR  DUP * ;  4 SQR CONSTANT FOO
  52.  
  53. >     f)   : SQCON  DUP * CONSTANT ;   4 SQCON FOO
  54.  
  55. All of them.
  56.  
  57. Cases e) and f) show the reason for this.  Removing this ability would
  58. virtually eliminate Forth's ability to create complex data structures,
  59. as well as breaking huge amounts of existing code.
  60.  
  61. > 10. What penalties are imposed upon vendors who wrongfully label
  62. >     cross-compilers "ANSI Standard"?
  63.  
  64. Judging from what I've seen of other languages, none.  Except, perhaps,
  65. public censure.  :-)
  66.  
  67. Writing cross-compilable code almost always entails using various
  68. extensions to specify whether words exist in the host or target system. 
  69. At some point, it would probably be a good idea to codify and
  70. standardize some of these extensions, and perhaps modify the standard to
  71. allow a normal standard system to recognise (and perhaps ignore) these
  72. extensions.  Until then, standard programs can not necessarily be
  73. cross-compiled, and standard systems may not be able to handle
  74. cross-compilable code.
  75.  
  76. At the moment, I think that this is an issue best left alone.  Brad
  77. seems to be proposing something that would virtually gut the standard,
  78. unless the issues I mention in the previous paragraph are dealt with.
  79.  
  80. Disclaimer:  my opinions only, I'm not a member of, or associated with,
  81. the ANS TC, or any company that has representitives on the TC.
  82. -- 
  83. Chris Waters    | the insane don't | NOBODY for President!
  84. xtifr@netcom.COM| need disclaimers | Because Nobody's perfect!!
  85.