DPANSA1.HTM (7409B)
1 <HTML><HEAD> 2 <TITLE>DPANS94</TITLE> 3 <link disabled rel="stylesheet" href="mpexc6.css"> 4 <style>@import url(mpexc6.css);</style> 5 </head> 6 7 <BODY> 8 <table width=100%> 9 <tr> 10 <td align=left> 11 <a href=dpans17.htm><img src=left.gif 12 width=26 height=26 align=ALIGN border=0></a> 13 <a href=dpansa2.htm><img src=right.gif 14 width=26 height=26 align=ALIGN border=0></a> 15 </td> 16 <td align=right> 17 <a href=dpans.htm#toc><img src=up.gif 18 width=26 height=26 align=ALIGN border=0></a> 19 <a name=A.>Table of Contents</a> 20 </td> 21 </tr> 22 </table> 23 <p> 24 <hr size=4> 25 26 <H1>A. Rationale (informative annex)</H1> 27 28 29 <hr> 30 <a name=A.1> 31 <H2>A.1 Introduction</H2> 32 </a> 33 34 <hr> 35 <a name=A.1.1></A> 36 <H3>A.1.1 Purpose</H3> 37 </a> 38 39 40 <hr> 41 <a name=A.1.2> 42 <H3>A.1.2 Scope</H3> 43 </a> 44 45 This Standard is more extensive than previous industry standards for the Forth 46 language. Several things made this necessary: 47 48 <UL> 49 <LI>the desire to resolve conflicts between previous standards; 50 <LI>the need to eliminate semantic ambiguities and other inadequacies; 51 <LI>the requirement to standardize common practice, where possible 52 resolving divergences in a way that minimizes the cost of compliance; 53 <LI>the desire to standardize common system techniques, including those 54 germane to hardware. 55 </UL> 56 <P> 57 58 The result of the effort to satisfy all of these objectives is a 59 Standard arranged so that the required word set remains small. Thus ANS 60 Forth can be provided for resource-constrained embedded systems. Words 61 beyond those in the required word set are organized into a number of 62 optional word sets and their extensions, enabling implementation of 63 tailored systems that are Standard. 64 65 <P> 66 67 When judging relative merits, the members of the X3J14 Technical 68 Committee were guided by the following goals (listed in alphabetic 69 order): 70 71 <P> 72 73 <DL> 74 <DT><B>Consistency</B> 75 <DD>The Standard provides a functionally complete 76 set of words 77 with minimal functional overlap. 78 79 <DT><B>Cost of compliance</B> 80 <DD>This goal includes such issues as common 81 practice, how 82 much existing code would be broken by the proposed change, and the amount of 83 effort required to bring existing applications and systems into conformity 84 with the Standard. 85 86 <DT><B>Efficiency</B> 87 <DD>Execution speed, memory compactness. 88 89 <DT><B>Portability</B> 90 <DD>Words chosen for inclusion should be free of 91 system-dependent 92 features. 93 94 <DT><B>Readability</B> 95 <DD>Forth definition names should clearly delineate 96 their 97 behavior. That behavior should have an apparent simplicity which supports 98 rapid understanding. Forth should be easily taught and support readily 99 maintained code. 100 101 <DT><B>Utility</B> 102 <DD>Be judged to have sufficiently essential functionality 103 and frequency 104 of use to be deemed suitable for inclusion.</DL> 105 106 107 <P> 108 109 <hr> 110 <a name=A.1.3> 111 <H3>A.1.3 Document organization</H3> 112 </a> 113 114 115 <hr> 116 <a name=A.1.3.1> 117 <H4>A.1.3.1 Word sets</H4> 118 </a> 119 120 From the beginning, the X3J14 Technical Committee faced not only 121 conflicting ideas as to what <B>real</B> Forth is, but also conflicting 122 needs of the various groups within the Forth community. At one extreme 123 were those who pressed for a <B>bare</B> Forth. At the other extreme 124 were those who wanted a <B>fat</B> Forth. Many were somewhere in 125 between. All were convinced of the rightness of their own position and 126 of the wrongness of at least one of the two extremes. The committee's 127 composition reflected this full range of interests. 128 129 <P> 130 131 The approach we have taken is to define a 132 <a href=dpans6.htm#6.1>Core word set</a> 133 establishing a 134 greatest lower bound for required system functionality and to provide a 135 portfolio of optional word sets for special purposes. This simple 136 approach parallels the fundamental nature of Forth as an extensible 137 language, and thereby achieves a kind of meta-extensibility. 138 139 <P> 140 141 With this key, high-level compromise, regardless of the actual makeup of 142 the individual word sets, a firm and workable framework is established 143 for the long term. One may or may not agree that there should be a 144 <a href=dpans13.htm>Locals word set</a>, 145 or that the word 146 <a href=dpans6.htm#6.2.0945>COMPILE,</a> 147 belongs in the 148 <a href=dpans6.htm#6.2>Core Extensions word set</a>. 149 But at least there is a mechanism whereby such 150 things can be included in a logical and orderly manner. 151 152 <P> 153 154 Several implications of this scheme of optional word sets are 155 significant. 156 157 <P> 158 159 First, ANS Forth systems can continue to be implemented on a greater 160 range of hardware than could be claimed by almost any other single 161 language. Since only the 162 Core word set is required, very limited 163 hardware will be able to accommodate an ANS Forth implementation. 164 165 <P> 166 167 Second, a greater degree of portability of applications, and of 168 programmers, is anticipated. The optional word sets standardize various 169 functions (e.g., floating point) that were widely implemented before, 170 but not with uniform definition names and methodologies, nor the same 171 levels of completeness. With such words now standardized in the 172 optional word sets, communications between programmers - verbally, via 173 magazine or journal articles, etc. - will leap to a new level of 174 facility, and the shareability of code and applications should rise 175 dramatically. 176 177 <P> 178 179 Third, ANS Forth systems may be designed to offer the user the power to 180 selectively, even dynamically, include or exclude one or more of the 181 optional word sets or portions thereof. Also, lower-priced products may 182 be offered for the user who needs the Core word set and not much more. 183 Thus, virtually unlimited flexibility will be available to the user. 184 185 <P> 186 187 But these advantages have a price. The burden is on the user to decide 188 what capabilities are desired, and to select product offerings 189 accordingly, especially when portability of applications is important. 190 We do not expect most implementors to attempt to provide all word sets, 191 but rather to select those most valuable to their intended markets. 192 193 <P> 194 195 The basic requirement is that if the implementor claims to have a 196 particular optional word set the entire required portion of that word 197 set must be available. If the implementor wishes to offer only part of 198 an optional word set, it is acceptable to say, for example, <B>This 199 system offers portions of the [named] word set</B>, particularly if the 200 selected or excluded words are itemized clearly. 201 202 <P> 203 204 Each optional word set will probably appeal to a particular 205 constituency. For example, scientists performing complex mathematical 206 analysis may place a higher value on the 207 <a href=dpans12.htm>Floating-Point word set</a> 208 than 209 programmers developing simple embedded controllers. As in the case of 210 the core extensions, we expect implementors to offer those word sets 211 they expect will be valued by their users. 212 213 <P> 214 215 Optional word sets may be offered in source form or otherwise factored 216 so that the user may selectively load them. 217 218 <P> 219 220 The extensions to the optional word sets include words which are deemed 221 less essential to performing the primary activity supported by the word 222 set, though clearly relevant to it. As in the case of the Core 223 Extensions, implementors may selectively add itemized subsets of a word 224 set extension providing the labeling doesn't mislead the user into 225 thinking incorrectly that all words are present. 226 227 <P> 228 229 <hr> 230 <A href=dpans.htm#toc><IMG src="up.gif" ></A> Table of Contents 231 <BR> 232 <A href=dpansa2.htm><IMG src="right.gif" ></A> 233 Next Section 234 <P> 235 </BODY> 236 </HTML>