Aa HH $ @d HHZZ$ff@  d' Footnote TableFootnote**.\t.\t/ - :;,.!?hp2 ' `*  `JTOCHeading1Heading2 Cartesian FormatingHoLImplementabilityIronman NonassignableSteelman Subarrays accessablealiasing delimiters designational indexable instantiationinstantiationsmulticharactermulticomputers nonassignableInonassociativenonequivalence nongeneric nonindirectinonlocal nonlocals nonverifiable@ optimizers provability$ subexpressionW uninitialized   EquationVariables> ) I > )<$lastpagenum> *<$monthname> <$daynum>, <$year> +<$hour>:<$minute00> <$AMPM> ,;<$monthname> <$daynum>, <$year> <$hour>:<$minute00> <$ampm> -"<$monthnum>/<$daynum>/<$shortyear> .<$monthname> <$daynum>, <$year> bl /"<$monthnum>/<$daynum>/<$shortyear> 0 <$fullfilename>2 1 <$filename>* 2 <$paratext[Title]> 3 <$paratext[Heading1]> 4 <$curpagenum>n 5 <$marker1> 6 <$marker2> 7 (Continued)Su 8+ (Sheet <$tblsheetnum> of <$tblsheetcount>)tna 9Heading & Page <$paratext> on page<$pagenum> :Pagepage<$pagenum>aig ;See Heading & Page%See <$paratext> on page<$pagenum>.ino < Table Alll7Table<$paranumonly>, <$paratext>, on page<$pagenum>o =Table Number & Page'Table<$paranumonly> on page<$pagenum>  FFA HHA NN PP RA  fCe>5y  s >5|  s>:=   >5 ;hn5 ! uuye5 " t:te5 # 5 $ nda5 % r5 & oe>5 '  > 5 ( "hn5 ) mor5 *  fu5 +  5 , a*5 - a[T5 .  pa=< / i=? 0 uum=@ 1  er=A 2  er=B 3  in=C 4 Sh5 5 e o5 6 t)t5 7 e& =H 8 r 5 9 a6 : $p6 ; gSe6 <  Se6 = x p6 > uno6 ?  Ta> @ c u, 6 A >pa6 B m6) C bag=f D $mo= E een= F  = G 6: H 6C I H6F J 6O K = L > M >& N R>8 O  f6` P s6i Q s6l R 6u S 6x T u6} U t6 V 6 W 6 X 6 Y 6 Z >9 [ 6 \ 6 ] 6 ^ 6 _ 6 ` 6 a 6 b 6 c 6 d > e d c6 h 6 j 7 k 7 l 7 r 7! s 7* t 7- u 76 v 79 w 7B x 7E y 7J z 7M { c7Z | 7] } 7d ~ 7g  7l 7o 7t 7w 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8# 8, d8/ 88 8? 8H 8K 8] 8` 8n 8q 8z 8} 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 9 9 9 9& 9) 9. 95 9: 9= 9E 9N 9Q 9V 9Y 9b 9e 9j 9{ 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9  9  9  :  :  :  :  :  :! :* :;  :D  :G  :L  :O  :X  :[  :`  :c  :h  :k  :  :  :  : ! : " : $ : & : + : , : 1 : 2 : 3 : 4 : 5 ; 8 ; 9 ; : ; ; ; < ; = ;$ > ;5 C ;> D ;A E ;Z F ;] G ;f H ;i I ;v J ;y K ;~ L ; M ; N ; O ; P ; Q ; R ; S ; T ; U ; V ; Z ; [ ; \ ; ] ; ^ ; _ ; ` ; a ; b ; c ; d ; e ; f ; g < h < i < n < o <" p <% q <. r <1 s <6 t <9 u <> v ? Double Line 5c>?=5e?>==P=Q H q@=B7"AA Single Line5hA@HZqB@C7q TableFootnoteEGxR qCB7 9EGxR EPwEPw  TableFootnoteod5pDRRZH5xE5 ZH Fe   ZH5zFN5ZH$lEE DZH5{G6 ZH @>?HDoe   ZH5}H6ZH$lGG d>IKKBZH>JI ileZH..K.` C 9.Parallel Processing @C` D  $ E [9A. Parallel Processing.  It shall be possible to define parallel processes. Processes Pw2 E eo[(i.e., activation instances of such a definition) may be initiated at any point within the @ E Yscope of the definition. Each process (activation) must have a name. It shall not be posN E Ysible to exit the scope of a process name unless the process is terminated (or uninitiat\@ E ed). j` F 5{ x G W9B. Parallel Process Implementation.  The parallel processing facility shall be de G Ssigned to minimize execution time and space. Processes shall have consistent seman G Qtics whether implemented on multicomputers, multiprocessors, or with interleaved @ G !execution on a single processor. ` H   I W9C. Shared Variables and Mutual Exclusion.  It shall be.possible to mark variables   I Wthat are shared among parallel processes. An unmarked variable that is assigned on one ses I EXpath and used on another shall cause a warning. It shall be possible efficiently to perin I Tform mutual exclusion in programs. The language shall not require any use of mutual l @ I exclusion. Ysi` J  f K leY9D. Scheduling.  The semantics of the built-in scheduling algorithm shall be first-in-{  K G\first-out within priorities. A process may alter its own priority. If the language provides . K ]a default priority for new processes it shall be the priority of its initiating process. The < K wWbuilt-in scheduling algorithm shall not require that simultaneously executed processes @ GJ K aSon different processors have the same priority. [Note that this rule gives maximum es X K onYscheduling control to the user without loss of efficiency. Note also that priority speci f K . Wfication does not impose a specific execution order among parallel paths and thus does otht@ K ar+not provide a means for mutual exclusion.] in` L  o M n \9E. Real Time.  It shall be possible to access a real time clock. There shall be translan. M JVtion time constants to convert between the implementation units and the program units  M b]for real time. On any control path, it shall be possible to delay until at least a specified r M geTtime before continuing execution. A process may have an accessible clock giving the p@ M ti>cumulative processing time (i.e., CPU time) for that process. ` N re r O slU9G.Asynchronous Termination.  It shall be possible to terminate another process. o O hiVThe terminated process may designate the sequence of statements it will execute in re@ O ot#sponse to the induced termination. ` P d  Q fi\9H.Passing Data.  It shall be possible to pass data between processes that do not share an* Q siXvariables. It shall be possible to delay such data transfers until both the sending and bl8@ Q t1receiving processes have requested the transfer. MF` R ns tT S en_9I. Signalling.  It shall be possible to set a signal (without waiting), and to wait for a ol b S po_signal (without delay, if it is already set). Setting a signal, that is not already set, shall n. p@ S a,cause exactly one waiting path to continue. M~` T ro sZH>KI ZH$lJJ rmid5LtanTT OZUV 5M5 t sZUV itNseUUe ! n. ZUV 5NPF5i9HZUV lMM  prZ$ 5O5 QsiZ$ bedata traPotUUe "  Z$ 5PN5dheZ$ lOO ZH5QD aigZH  a''Ral'` # alDEPARTMENT OF DEFENSE ` alREQUIREMENTS FOR HIGH ORDER $` acCOMPUTER PROGRAMMING LANGUAGES M2` ro s@` STEELMAN IN`  \`  June 1978 j` mi x` 5PREFACE `  T` $ O  % 5T The Department of Defense Common High Order Language program was established in  % X1975 with the goal of establishing a single high order computer programming language ap % Qpropriate for DoD embedded computer systems. A High Order Language Working Group  % T(HOLWG) was established to formulate the DoD requirements for high order languages,  % Xto evaluate existing languages against those requirements, and to implement the minimal  % [set of languages required for DoD use. As an administrative initiative toward the eventual  % RTPgoal, DoD Directive 5000.29 provides that any new defense systems should be pro  % GRXgrammed in a DoD approved and centrally controlled high order language. DoD Instruction  % M5000.31 gives an interim list of approved languages: COBOL, FORTRAN, TACPOL,   % VCMS-2, SPL/1, and JOVIAL J3 and J73. Economic analyses that were used to quantify the . % p]benefits from increased use of high order languages, also showed that the rapid introduction i< % prWof a single modern language would increase the benefits considerably. The requirements . AJ % geXhave been widely distributed for comment throughout the military and civil communities, meX % lJproducing successively more refined versions from STRAWMAN through WOODENf % ndJMAN, TINMAN, IRONMAN, and the present STEELMAN. During the requirement det % aWvelopment process, it was determined that the single set of requirements generated was 50 % t Xboth necessary and sufficient for all major DoD applications. Formal evaluation was perd  % edUformed on dozens of existing languages concluding that no existing language could be l % ngZadopted as a single common HoL for the DoD but that a single language meeting essentially  % haZall the requirements was both feasible and desirable. Four contractors were funded to pro % owYduce competing prototype designs. After analysis of these preliminary designs the number r % coZof design teams was reduced to two. Their designs will be completed and a single language  % mi\will emerge. Further steps in the program will include test and evaluation of the language, io % hrZproduction of compilers and other tools for software development and maintenance, control  % Wof the language, and validation of compilers. Government-funded compilers and software s g % _tools, as well as the compiler validation facility, will be widely and inexpensively available wa@ % and well maintained. e` & gu sZH5RD lZH$lTQQ DoDZH5SL ay ZHal..oth feasTab.` ' fuTHE TECHNICAL REQUIREMENTS ow` ( ro y$` ) an s2 * inV The technical requirements for a common DoD high order programming language given @ * mpZhere arc a synthesis of the requirements submitted by the Military Departments. They specN * anZify a set of constraints on the design of languages that are appropriate for embedded com\ * elYputer applications (i.e., command and control, communications, avionics, shipboard, test mj * -fUequipment, software development and maintenance, and support applications). We would lx * wiZespecially like to thank the phase one analysis teams, the language design teams, and the  * sTmany other individuals and organizations that have commented on the Revised Ironman  * Zand have identified weaknesses and trouble spots in the technical requirements. A primary @ * Sgoal in this revision has been to reduce the complexity of the resulting language. ` (` +   n , *] This revision incorporates the following changes. Care has been taken to ensure that the  , heUparagraph numbers remain the same as in the Revised Ironman. There have been several  , anXchanges in terminology and many changes in wording to improve the understandability and m , elWpreciseness of the requirements. Several requirements have been restated to remove cont m , -fZstraints that were unintended but were implied because the requirement suggested a partic , esSular mechanism rather than giving the underlying requirement. The requirements for he  , sVembedded comments (2I), unordered enumeration types (3-2B), associative operator spec  , Zifications (7D), dynamic aliasing of array components (10B), and multiple representations . , Xof data (11B) have been deleted because they have been found unnecessary or are not ade< ,  Yquately justified. The minimal source language character set has been reduced to 55 chareJ , thVacters to make it compatible with the majority of existing input devices (2A). The do X , sWtogether model for parallel processing-has been found inadequate for embedded computer ve f , it\applications and has been replaced by a requirement for parallel processes (section 9). The ret , onXpreliminary designs have demonstrated the need for additional requirements for explicit re , arYconversion between types (3B), subtype constraints (3D), renaming (3-5B), a language dis  , e Ztinction between open and closed scopes (5G), and the ability, but preferably not special  , \mechanisms, to pass data between parallel processes (9H), to write nonverifiable assertions pr@ , [(10F), to wait for several signals simultaneously (9J), and to mark shared variables (9C). no` -    . d.^ The Steelman is organized with an outline similar to that expected in a language defining  . mpZdocument. Section 1 gives the general design criteria. These provide the major goals that  . le]influenced the selection of more specific requirements in later sections and provide a basis o . plZfor language design decisions that are not otherwise addressed in this document. Sections  . d[2 through 12 give more specific constraints on the language and its translators. The Steelion . ),\man calls for the inclusion of features to satisfy specific needs in the design, implementawe . sPtion, and maintenance of military software, specifies both general and specific an* . b]characteristics desired for the language, and calls for the exclusion of certain undesirable ,8 . al[characteristics. Section 13 gives some of the intentions and expectations for development,  F . d.Xcontrol, and use of the language. The intended use and environment for the language has inT@ . .Pstrongly influenced the requirements, and should influence the language design. orb` 0   .p 1 he[ A precise and consistent use of terms has been attempted throughout the document. Many .~ 1 dYpotentially ambiguous terms have been defined in the text. Care has been taken to distin.ZH5TLrntZH$lRWSS d5UareWWs tZH5VU stiZH mies bothWpe@ 1 bSguish between requirements, given as text, and comments, given as bracketed notes. des 2 XThe following terms have been used throughout the text to indicate where and to what deve$@ 2 #gree individual constraints apply: la2` M ed e@` 3 orDshall:indicates a requirement placed on the language or translator irU` 4 iNshould:indicates a desired goal but one for which there is no objective test j 8 Ushall attempt:indicates a desired goal but one that may not be achievable given the  8 llFcurrent state-of-the-art, of may be in conflict with other more impor@ 8 tant requirements. L Rshall require:indicates a requirement placed on the user by the language and its @ re"translators (language is subject)  5Rshall permit:indicates a requirement placed on the language to provide an option @ "to the user (language is subject)  n Imust:indicates a requirement placed on the user by the language and its h@ hatranslators (user is subject) ' aImay:indicates a requirement placed on the language to provide an option a<@ edto the user (user is subject) Q reLwill:indicates a consequence that is expected to follow or indicates an incaf bGtention of the DoD; it does not in any case by itself constrain the dette{@ essign of the language m leQtranslation:refers to any processing applied to a program by the host or object i rEmachine before execution; it includes lexical analysis, syntactic er  aBror checking, program analysis, optimization, code generation, as@ orsembly, and loading )  5Nexecution:refers to the processing by the object machine to carry out the ac@ !tions prescribed by the program. e` /  ZH5WUhusZH$lTZVV  (ud6?XiicZZonheZH6@YX ZHr .. reZte.` 5 pe1.General Design Criteria n i` 6  b$ 7 oD[1A. Generality.  The language shall provide generality only to the extent necessary to gua2 7 Tsatisfy the needs of embedded computer applications. Such applications involve real i@ 7 rYtime control, self diagnostics, input-output to nonstandard peripheral devices, parallel aN@ 7 og6processing, numeric computation, and file processing. \` ly nj 9 Y1B. Reliability.  The language should aid the design and development of reliable prox 9 Tgrams. The language shall be designed to avoid error prone features and to maximize  9 usQautomatic detection of programming errors. The language shall require some redun 9 Xdant, but not duplicative, specifications in programs. Translators shall produce explan 9 r Tatory diagnostic and warning messages, but shall not attempt to correct programming al@ 9 ierrors. ` :   ; erU1C. Maintainability.  The language should promote ease of program maintenance. It  ; saWshould emphasize program readability (i.e., clarity, understandability, and modifiabil ; cSity of programs). The language should encourage user documentation of programs. It N ; prXshall require explicit specification of programmer decisions and shall provide defaults 9 ; liUonly for instances where the default is stated in the language definition, is always  ; heUmeaningful, reflects the most frequent usage in programs, and may be explicitly over @ ; c ridden. of.` < s. e< = quZ1D. Efficiency.  The language design should aid the production of efficient object proJ = pTgrams. Constructs that have unexpectedly expensive implementations should be easily nX = ecUrecognizable by translators and by users. Features should be chosen to have a simple ;f = abSand efficient implementation in many object machines, to avoid execution costs for ;t = siUavailable generality where it is not needed, to maximize the number of safe optimiza = roWtions available to translators, and to ensure that unused and constant portions of pro ; = e Ngrams will not add to execution costs. Execution time support packages of the @ = onFlanguage shall not be included in object code unless they are called. ` >   ? ulV1E. Simplicity.  The language should not contain unnecessary complexity. It should  ? ofQhave a consistent semantic structure that minimizes the number of underlying cong ? roScepts. It should be as small as possible consistent with the needs of the intended xpe ? mpTapplications. It should have few special cases and should be composed from features by ? hoVthat are individually simple in their semantics. The language should have uniform syn ? , Utactic conventions and should not provide several notations for the same concept. No n@ ? mi?arbitrary restriction should be imposed on a language feature. abl` A an o* B d V1F. Implementability.  The language shall be composed from features that are under8 B e Sstood and can be implemented. The semantics of each feature should be sufficiently t cF B e [well specified and understandable that it will be possible to predict its interaction with noT B arZother features. To the extent that it does not interfere with other requirements, the lanb B f Xguage shall facilitate the production of translators that are easy to implement and are wip B e Vefficient during translation. There shall be no language restrictions that are not en~@ B omforceable by translators. ZH6BZX maZH$lW]YY d6[ ve]] cceZH6\[ tctZHon] o` C Im m H e V1G. Machine Independence.  The design of the language should strive for machine in$ H . Ydependence. It shall not dictate the characteristics of object machines or operating sysd2 H e Ttems except to the extent that such characteristics are implied by the semantics of r @ H xtXcontrol structures and built-in operations. It shall attempt to avoid features whose see N H heTmantics depend on characteristics of the object machine or of the object machine opef\ H nsWerating system. Nevertheless, there shall be a facility for defining those portions of ceaj H . Vprograms that are dependent on the object machine configuration and for conditionally x@ H :compiling programs depending on the actual configuration. ` I c e J S1H. Complete Definition.  The language shall be completely and unambiguously de J Zfined. To the extent that a formal definition assists in achieving the above goals (i.e., @ J st;all of section 1), the language shall be formally defined. l n` K ra r` D ac eZH6][e eZH$lZ`\\ thed7V^ost``atnsZH7W_^ se ZHma..ristics `ma.` P hi2.General Syntax ` Q sy m$ R erZ2A. Character Set.  The full set of character graphics that may be used in source pro2 R heVgrams shall be given in the language definition. Every source program shall also have @@ R thYa representation that uses only the following 55 character subset of the ASCII graphics: oN` S e  l\` T d  %&()*+,-./:;<=>? j` U fi 0l23456789 xtex` V efABCDEFGHIJKLMNOPQRSTUVWXYZ_ he` W ,   X al[Each additional graphic (i.e., one in the full set but not in the 55 character set) may be  X Ureplaced by a sequence of (one or more) characters from the 55 character set without  X Valtering the semantics of the program. The replacement sequence shall be specified in @ X the language definition. ` Y   Z s U2B. Grammar.  The language should have a simple, uniform, and easily parsed gramm Z erVmar and lexical structure. The language shall have free form syntax and should use fa@ Z RDmiliar notations where such use does not conflict with other goals. og` \ e   N a X2C. Syntactic Extensions.  The user shall not be able to modify the source language   N lYsyntax. In particular the user shall not be able to introduce new precedence rules or to .@ N IJdefine new syntactic forms. <` ]  J ^ itV2D. Other Syntactic Issues.  Multiple occurrences of a language defined symbol apX ^ reYpearing in the same context shall not have essentially different meanings. Lexical units f ^ riS(i.e., identifiers, reserved words, single and multicharacter symbols, numeric and t ^ laVstring literals, and comments) may not cross line boundaries of a source program. All  ^ veWkey word forms that contain declarations or statements shall be bracketed (i.e., shall re. ^ l Shave a closing as well as an opening key word). Programs may not contain unmatched suc@ ^ brackets of any kind. ` _ e   ` a V2E. Mnemonic Identifiers.  Mnemonically significant identifiers shall be allowed.  ` NXThere shall be a break character for use within identifiers. The language and its transr  ` NYlators shall not permit identifiers or reserved words to be abbreviated. (Note that this r@ `  Tdoes not preclude reserved words that are abbreviations of natural language words.) in` a sh  b lyW2F. Reserved Words.  The only reserved words shall be those that introduce special rds b chYsyntactic forms (such as control structures and declarations) or that are otherwise used t b riWas delimiters. Words that may be replaced by identifiers, shall not be reserved (e.g., s o* b bYnames of functions, types, constants, and variables shall not be reserved). All reserved w8@ b n2words shall be listed in the language definition. F` c  T d Z2G. Numeric Literals.  There shall be built-in decimal literals. There shall be no imb@ d Cplicit truncation or rounding of integer and fixed point literals. ierp` h d  ~ j ^2H.String Literals.  There shall be a built-in facility for fixed length string literals. ZH7Y`^ seZH$l]c__  ind7ay2Fcc oy ZH7ba epeZHR buch as ccre@ j t JString literals shall be interpreted as one-dimensional character arrays. ` k ie $ l veV2I.Comments.  The language shall permit comments that are introduced by a special 2 l d)U(one or two character) symbol and terminated by the next line boundary of the source @@ l program. N` r N rZH7cacalZH$l`fbb trud8;di lff hd ZH8<ed l ZHil..length sf. .` s  3.Types ` t  $ u Y3A. Strong Typing.  The language shall be strongly typed. The type of each variable, 2 u Rarray and record component, expression, function, and parameter shall be determin@@ u able during translation. N` v ng t\ w erW3B.Type Conversions.  The language shall distinguish the concepts of type (specifyV2Ij w e Ving data elements with common properties, including operations), subtype (i.e., a subx w r)Rset of the elements of a type, that is characterized by further constraints), and  w Wrepresentations (i.e., implementation characteristics). There shall be no implicit conl w Vversions between types. Explicit conversion operations shall be automatically defined @ w Ebetween types that are characterized by the same logical properties. ` x s  y .\3C. Type Definitions.  It shall be possible to define new data types in programs. A type ng y sYmay be defined as an enumeration, an array or record type, an indirect type, an existing c y onYtype, or a subtype of an existing type. It shall be possible to process type definitions  y ngXentirely during translation. An identifier may be associated with each type. No restricce@ y fyOtion shall be imposed on user defined types unless it is imposed on all types. rat` z e.  { wW3D. Subtype Constraints.  The constraints that characterize subtypes shall include   { reXrange, precision, scale, index ranges, and user defined constraints. The value of a sub. { veWtype constraint for a variable may be specified when the variable is declared. The lan< { eeWguage should encourage such specifications. [Note that such specifications can aid the J@ { 3CDclarity, efficiency, maintainability, and provability of programs.] inX` | ng f` } ma3.1. Numeric Types umet` ~ r  o  ctV3-1A. Numeric Values.  The language shall provide distinct numeric types for exact   prNand for approximate computation. Numeric operations and assignment that would   soYcause the most significant digits of numeric values to be truncated (e.g., when overflow i@  t 1occurs) shall constitute an exception situation. ` w D in[3-1B. Numeric Operations.  There shall be built-in operations (i.e., functions) for conge, iXversion between the numeric types. There shall be operations for addition, subtraction, c riVmultiplication, division, negation, absolute value, and exponentiation to integer pow geZers for each numeric type. There shall be built-in equality (i.e., equal and unequal) and  m\ordering operations (i.e., less than, greater than, less than or equal, and greater than or 3. meSequal) between elements of each numeric type. Numeric values shall be equal if and sha@ t 3only if they have exactly the same abstract value. ap*` io N8 anU3-1C. Numeric Variables.  The range of each numeric variable must be specified in rF unTprograms and shall be determined by the time of its allocation. Such specifications n T Oshall be interpreted as the minimum range to be implemented and as the maximum e bb (Vrange needed by the application. Explicit conversion operations shall not be required p@ iobetween numeric ranges. on~`  iZH8>fdu vZH$lciee Zerd8glinii uquZH8hg aonZHea..qual, ani  o.` eqApproximate Arithmetic eac` me $ ua\3-1D. Precision.  The precision (of the mantissa) of each expression result and variable 2 Uin approximate computations must be specified in programs, and shall be determinable b@ Wduring translation. Precision specifications shall be required for each such variable. eciN WSuch specifications shall be interpreted as the minimum accuracy (not significance) to mum\ Sbe implemented. Approximate results shall be implicitly rounded to the implemented quij@ Jprecision. Explicit conversions shall not be required between precisions. x`  u P3-1E. Approximate Arithmetic Implementation.  Approximate arithmetic will be  Wimplemented using the actual precisions, radix, and exponent range available in the ob Xject machine. There shall be built-in operations to access the actual precision, radix, @ *and exponent range of the implementation. ` he n` reExact Arithmetic r`   teT3-1F. Integer and Fixed Point Numbers.  Integer and fixed point numbers shall be  laVtreated as exact numeric values. There shall be no implicit truncation or rounding in @ ci&integer and fixed point computations. `  n  \3-1G. Fixed Point Scale.  The scale or step size (i.e., the minimal representable differme. Tence between values) of each fixed point variable must be specified in programs and <@ uUbe determinable during translation. Scales shall not be restricted to powers of two. hJ`  X emX3-1H. Integer and Fixed Point Operations.  There shall be integer and fixed point opf mTerations for modulo and integer division and for conversion between values with dift anWferent scales. All built-in and predefined operations for exact arithmetic shall apply ct  Xbetween arbitrary scales. Additional operations between arbitrary scales shall be definnd@ rsable within programs. ` as a` T3.2.Enumeration Types tr` ng  ciW3-2A.Enumeration Type Definitions.  There shall be types that are definable in proG.   Sgrams by enumeration of their elements. The elements of an enumeration type may be  ueZidentifiers or character literals. Each variable of an enumeration type may be restricted @ ng0to a contiguous subsequence of the enumeration. we`   U3-2B.Operations on Enumeration Types.  Equality, inequality, and the ordering opf Serations shall be automatically defined between elements of each enumeration type. va* WSufficient additional operations shall be automatically defined so that the successor, tic8 Ypredecessor, the position of any element, and the first and last element of the type may sF@ be computed. sT` ra b` asM3-2C.Boolean Type.  There shall be a predefined type for Boolean values. p` 3- ~ efX3-2D.Character Types.  Character sets shall be definable as enumeration types. Chars ZH8ign oZH$lflhh ierd91jnnullicd ZH92kj qncZHwe..l 3-. ioWacter types may contain both printable and control characters. The ASCII character set all@ deshall be predefined. o$` t .2`  @` E io3.3 Composite Types e N` ne o\ r,Z3-3A.Composite Type Definitions.  It shall be possible to define types that are Cartej mYsian products of other types. Composite types shall include arrays (i.e., composite data x ThRwith indexable components of homogeneous types) and records (i.e., composite data @ .0with labeled components of heterogeneous type). ab` ty . V3-3B.Component Specifications.  For elements of composite types, the type of each  Vcomponent (i.e., field) must be explicitly specified in programs and determinable dur Sing translation. Components may be of any type (including array and record types).  VRange, precision, and scale specifications shall be required for each component of ap@ propriate numeric type. ne`  t S3-3C.Operations on Composite Types.  A value accessing operation shall be auto mpRmatically defined for each component of composite data elements. Assignment shall  siUbe automatically defined for components that have alterable values. A constructor op  Th]eration (i.e., an operation that constructs an element of a type from its constituent parts) . elTshall be automatically defined for each composite type. An assignable component may 3-< ifTbe used anywhere in a program that a variable of the component's type is permitted. coJ ldTThere shall be no automatically defined equivalence operations between values of elinX@ poements of a composite type. udf` rd pt X3-3D. Array Specifications.  Arrays that differ in number of dimensions or in compoof Xnent type shall be of different types. The range of subscript values for each dimension io peWmust be specified in programs and may be determinable at the time of array allocation. ed  oVThe range of each subscript value must be restricted to a contiguous sequence of inte@ th;gers or to a contiguous sequence from an enumeration type. Th` n  r ctX3-3E. Operations on Subarrays.  There shall be built-in operations for value access, ic acSassignment, and catenation of contiguous sections of one-dimensional arrays of the e i vQsame component type. The results of such access and catenation operations may be e@ de used as actual input parameter. en`   tsU3-3F.Nonassignable Record Components.  It shall be possible to declare constants i aySand (unary) functions that may be thought of as record components and may be referhal* tySenced using the same notation as for accessing record components. Assignment shall sp8@ s %not be permitted to such components. aF` d  T Th\3-3G.Variants.  It shall be possible to define types with alternative record structures b@ toZ(i.e., variants). The structure of each variant shall be determinable during translation. p` io o~ heZ3-3H.Tag Fields.  Each variant must have a nonassignable tag field (i.e., a component ZH94ljnonZH$liokk . Td9metioo deZH9nm ZH..nable Reo s.. toWthat can be used to discriminate among the variants during execution). It shall not be re@ d Dpossible to alter a tag field without replacing the entire variant. f$` d  p2 s]3-3I. Indirect Types.  It shall be possible to define types whose elements are indirectly @ 3-Qaccessed. Elements of such types may have components of their own type, may have cN Tsubstructure that can be altered during execution, and may be distinct while having t\ Uidentical component values. Such types shall be distinguishable from other composite nj ldZtypes in their definitions. An element of an indirect type shall remain allocated as long x Was it can be referenced by the program. [Note that indirect types require pointers and @ 1sometimes heap storage in their implementation.] `   X3-3J. Operations on Indirect Types.  Each execution of the constructor operation for nt ).Wan indirect type shall create a distinct element of the type. An operation that distin th fTguishes between different elements, an operation that replaces all of the component ss esXvalues of an element without altering the element's identity, and an operation that pro h thRduces a new element having the same component values as its argument, shall be au@ ay,tomatically defined for each indirect type. ` en a` ha 3.4.Sets ` er m  ]3-4A. Bit Strings (i.e., Set Types).  It shall be possible to define types whose elements l. Tare one-dimensional Boolean arrays represented in maximally packed form (i.e, whose rs<@ elements are sets). apJ` im mX X3-4B. Bit String Operations.  Set construction, membership (i.e., subscription), set onf r Requivalence and nonequivalence, and also complement, intersection, union, and symt oUmetric difference (i.e., component-by-component negation, conjunction, inclusive dise esNjunction, and exclusive disjunction respectively) operations shall be defined @ id!automatically for each set type. h` th u` ha3.5.Encapsulated Definitions ` al e [3-5A.Encapsulated Definitions.  It shall be possible to encapsulate definitions. An enha Ucapsulation may contain declarations of anything (including the data elements and op  inUerations comprising a type) that is definable in programs. The language shall permit e@ pa6multiple explicit instantiations of an encapsulation. `   W3-5B.Effect of Encapsulation.  An encapsulation may be used to inhibit external acipt \cess to implementation properties of the definition. In particular, it shall be possible to m* oVprevent external reference to any declaration within the encapsulation including auto8 esUmatically defined operations such as type conversions and equality. Definitions that F maUare made within an encapsulation and are externally accessible may be renamed before aT@ use outside the encapsulation. b` ul dp ItV3-5C. Own Variables.  Variables declared within an encapsulation, but not within a ~ Xfunction, procedure, or process of the encapsulation, shall remain allocated and retain prZH9om.heZH$llrnn it d9prr ZH9qp aulZH(nhr  t@ s Ntheir values throughout the scope in which the encapsulation is instantiated. ` r r$`  at ZH:rpZH$louqq rsid:}suuanncZH:~ts ye ZH<))e the enu  )` 4.Expressions V3-`   V$ wiX4A. Form of Expressions.  The parsing of correct expressions shall not depend on the es2 tiWtypes of their operands or on whether the types of the operands are built into the lanZ@@ guage. N` n \ [4B. Type of Expressions.  It shall be possible to specify the type of any expression exj Yplicitly. The use of such specifications shall be required only where the type of the exx tVpression cannot be uniquely determined during translation from the context of its use @ at'(as might be the case with a literal). `   Z4C. Side Effects.  The language shall attempt to minimize side effects in expressions,  ^but shall not prohibit all side effects. A side effect shall not be allowed if it would alter  Zthe value of a variable that can be accessed at the point of the expression. Side effects  esWshall be limited to own variables of encapsulations. The language shall permit side efti peUfects that are necessary to instrument functions and to do storage management within  Yfunctions. The order of side effects within an expression shall not be guaranteed. [Note  e Ythat the latter implies that any program that depends on the order of side effects is erl@ wh roneous.] `    F cV4D.Allowed Usage.  Expressions of a given type shall be allowed wherever both con.@ F t .stants and variables of the type are allowed. <`  J ecU4E. Translation Time Expressions.  Expressions that can be evaluated during transX l Xlation shall be permitted wherever literals of the type are permitted. Translation time f va\expressions that include only literals and the use of translation time facilities (see 11C) t@ l'shall be evaluated during translation. . T` pe t W4F.Operator Precedence Levels.  The precedence levels (i.e., binding strengths) of nt  Zall (prefix and infix) operators shall be specified in the language definition, shall not  Wbe alterable by the user, shall be few in number, and shall not depend on the types of cts@ the operands. `   F^4G. Effect of Parentheses.  If present, explicit parentheses shall dictate the association  stVof operands with operators. The language shall specify where explicit parentheses are  TiSrequired and shall attempt to minimize the psychological ambiguity in expressions. l  peW[Note that this might be accomplished by requiring explicit parentheses to resolve the va iWoperator-operand association whenever a nonassociative operator appears to the left of @  Tan operator of the same precedence at the least-binding precedence level of any sub P*@ expression.] e8` di sZH:uspfiZH$lrxtt inid:vtabxxewn ZH:wv ftsZHth##` x#` re$5.Constants, Variables, and Scopes nt` e  $ Z5A. Declarations of Constants.  It shall be possible to declare constants of any type. 2 SSuch constants shall include both those whose values-are determined during translassi@ Stion and those whose value cannot be determined until allocation. Programs may not resN@ assign to constants. o\` w ej veX5B. Declarations of Variables.  Each variable must be declared explicitly. Variables cex inWmay be of any type. The type of each variable must be specified as part of its declara s Ttion and must be determinable during translation. [Note, "variable" throughout this  Tdocument refers not only to simple variables but also to composite variables and to :@ f#components of arrays and records.] `   #V5C. Scope of Declarations.  Everything (including operators) declared in a program  5AZshall have a scope (i.e., a portion of the program in which it can be referenced). Scopes  SuVshall be determinable during translation. Scopes may be nested (i.e., lexically embed tiVded). A declaration may be made in any scope. Anything other than a variable shall be @ as6accessable within any nested scope of its definition. ` ar o \5D. Restrictions on Values.  Procedures, functions, types, labels, exception situations, pe  vWand statements shall not be assignable to variables, be computable as values of exprese d.@ tIsions, or be usable as nongeneric parameters to procedures or functions. e<` t iJ` aP5E. Initial Values.  There shall be no default initial-values for variables. rX`  f S5F. Operations on Variables.  Assignment and an implicit value access operation d it@ 2shall be automatically defined for each variable. ` ic t ).V5G. Scope of Variables.  The language shall distinguish between open scopes (i.e.,  llXthose that are automatically included in the scope of more globally declared variables) t llYand closed scopes (i.e., those in which nonlocal variables must be explicitly Imported).  VBodies of functions, procedures, and processes shall be closed scopes. Bodies of clas@ pe/sical control structures shall be open scopes. as` le b` lu oZH:xv uZH$lu{ww <d;ryEIn{{albeZH;szy rZH.((erations{ (` ci 6.Classical Control Structures ` l  a$ edW6A. Basic Control Facility.  The (built-in) control mechanisms should be of minimal  2 llVnumber and complexity. Each shall provide a single capability and shall have a distin@ sWguishing syntax. Nesting of control structures shall be allowed. There shall be no con, tN ocUtrol definition facility. Local scopes shall be allowed within the bodies of control p\ Zstatements. Control structures shall have only one entry point and shall exit to a single j s.Zpoint unless exited via an explicit transfer of control (where permitted, see 6G), or the x@ #raising of an exception (see 10C). u{`    U6B. Sequential Control.  There shall be a control mechanism for sequencing state  Rments. The language shall not impose arbitrary restrictions on programming style,   CVsuch as the choice between statement terminators and statement separators, unless the @  lt2restriction makes programming errors less likely. `  nu r  ac[6C. Conditional Control.  There shall be conditional control structures that permit senta  roVlection among alternative control paths. The selected path may depend on the value of   caVa Boolean expression, on a computed choice among labeled alternatives, or on the true   es[condition in a set of conditions. The language shall define the control action for all vals e  ciXues of the discriminating condition that are not specified by the program. The user may n    ).Zsupply a single control path to be used when no other path is selected. Only the selected .  isTbranch shall be compiled when the discriminating condition is a translation time exit<@  on pression. J`   X  ch]6D. Short Circuit Evaluation.  There shall be infix control operations for short circuit ef  ogUconjunction and disjunction of the controlling Boolean expression in conditional and nt@  eriterative control structures. `  mi e  \6E. Iterative Control.  There shall be an iterative control structure. The iterative con  a Wtrol may be exited (without reentry) at an unrestricted number of places. A succession   itUof values from an enumeration type or the integers may be associated with successive e  ciYiterations and the value for the current iteration accessed as a constant throughout the @  ). loop body. ngl`  be e th[6G. Explicit Control Transfer.  There shall be a mechanism for control transfer (i.e., imi s ]the go to). It shall not be possible to transfer out of closed scopes, into narrower scopes,  ir\or into control structures. It shall be possible to transfer out of classical control struc  anVtures. There shall be no control transfer mechanisms in the form of switches, designa@ ntLtional expressions, label variables, label parameters, or alter statements. nt*` ll ZH;u{yvcoZH$lx~zz ) ad;|on~~ofalZH;}| sayZHcc.. ciYit~he.`  ra7.Functions and Procedures ro`   $  y.U7A. Function and Procedure Definitions.  Functions (which return values to expresh2  haTsions) and procedures (which can be called as statements) shall be definable in propo@  oVgrams. Functions or procedures that differ in the number or types of their parameters N  poUmay be denoted by the same identifier or operator (i.e., overloading shall be permits\  tYted). [Note that redefinition, as opposed to overloading, of an existing function or prosj@  lcedure is often error prone.] x`   `  W7B. Recursion.  It shall be possible to call functions and procedures recursively. zz`     Y7C. Scope Rules.  A reference to an identifier that is not declared in the most local y  \scope shall refer to a program element that is lexically global, rather than to one that is a@  .global through the dynamic calling structure. `  re f`  ti Functions `  pr h  haZ7D. Function Declarations.  The type of the result for each function must be specified   grZin its declaration and shall be determinable during translation. The results of functions   beYmay be of any type. If a result is of a nonindirect array or record type then the number  @  otEof its components must be determinable by the time of function call. .`   <` G te Parameters .] J`   X  U7F. Formal Parameter Classes.  There shall be three classes of formal data parame.f  \ters: (a) input parameters, which act as constants that are initialized to the value of corclt  ocUresponding actual parameters at the time of call, (b) input-output parameters, which a  onTenable access and assignment to the corresponding actual parameters, either through  Xout execution or only upon call and prior to any exit, and (c) output parameters, whose la  ypXvalues are transferred to the corresponding actual parameter only at the time of normal on  rmXexit. In the latter two cases the corresponding actual parameter shall be determined at pe@  f Ttime of call and must be a variable or an assignable component of a composite type. ne` ! in e " ncW7G. Parameter Specifications.  The type of each formal parameter must be explicitly  " Vspecified in programs and shall be determinable during translation. Parameters may be  " Zof any type. The language shall not require user specification of subtype constraints for  " Xformal parameters. If such constraints are permitted they shall be interpreted as asserhi " Ttions and not as additional overloading. Corresponding formal and actual parameters ug@ " must be of the same type. *` $ r  a8 L utS7H. Formal Array Parameters.  The number of dimensions for formal array paramedinF L oWters must be specified in programs and shall be determinable during translation. DeterspoT L etQmination of the subscript range for formal array parameters may be delayed until lb L cWinvocation and may vary from call to call. Subscript ranges shall be accessible within er p@ L  Kfunction and procedure bodies without being passed as explicit parameters. Vsp~` & s  ZH;~|ameZH$l{}} d<* ns "ZH<+ eerZH|nt  s  + loY7I. Restrictions to Prevent Aliasing.  The language shall attempt to prevent aliasing m + Z(l.e., multiple access paths to the same variable or record component) that is not intend$ + paXed, but shall not prohibit all aliasing. Aliasing shall not be permitted between output d2 + DSparameters nor between an input-output parameter and a nonlocal variable. Unintendter@ + ntVed aliasing shall not be permitted between input-output parameters. A restriction limN + wiQiting actual input-output parameters to variables that are nowhere referenced as \ + s.Ynonlocals within a function or routine, is not prohibited. All aliasing of components of j@ + >elements of an indirect type shall be considered intentional. x` ,  ZH<-+ZH$l~ d  9ZH sf  :ZH>! CtrZHD as to intos U roZ9J. Waiting.  It shall be possible to wait for, determine, and act upon the first com U sZpleted of several wait operations (including those used for data passing, signalling, and $@ U  real time). e 2` V on o@` Z he mZH>#rreZH$lK e (d>'gs ti eZH>( ZHpe..ame sema s.` [ an10. Exception Handling gra` \ > $ ] U10A. Exception Handling Facility.  There shall be an exception handling mechanism 2 ] Ufor responding to unplanned error situations detected in declarations and statements @ ] Vduring execution. The exception situations shall include errors detected by hardware, N ] roXsoftware errors detected during execution, error situations in built-in operations, and m\ ] sUuser defined exceptions. Exception identifiers shall have a scope. Exceptions should j@ ] U?add to the execution time of programs only if they are raised.  mx` ^  # _ rZ10B. Error Situations.  The errors detectable during execution shall include exceeding  _ gXthe specified range of an array subscript, exceeding the specified range of a variable,  _ .Uexceeding the implemented range of a variable, attempting to access an uninitialized  _ Yvariable, attempting to access a field of a variant that is not present, requesting a rea _ ngWsource (such as stack or heap storage) when an insufficient quantity remains, and failn d _ atTing to satisfy a program specified assertion. [Note that some are very expensive to e _ haXdetect unless aided by special hardware, and consequently their detection will often be in@ _ nssuppressed (see 10G).] s` ` ep n a if[10C. Raising Exceptions.  There shall be an operation that raises an exception. Raising f p a eyWan exception shall cause transfer of control to the most local enclosing exception hanThe  a dWdler for that exception without completing execution of the current statement or declarra. a diYration, but shall not of itself cause transfer out of a function, procedure, or process. g< a ttXExceptions that are not handled within a function or procedure shall be raised again at fJ a th[the point of call in their callers. Exceptions that are not handled within a process shall ge)X a enYterminate the process. Exceptions that can be raised by built-in operations shall be givsf@ a sen in the language definition. t` b ct l c alY10D. Exception Handling.  There shall be a control structure for discriminating among d c Uthe exceptions that can occur in a specified statement sequence. The user may supply n c isVa single control path for all exceptions not otherwise mentioned in such a discrimina c lYtion. It shall be possible to raise the exception that selected the current handler when e@ c thexiting the handler. d` d  a e shX10E. Order of Exceptions.  The order in which exceptions in different parts of an ex a@ e haTpression are detected shall not be guaranteed by the language or by the translator. ` f t  c g rs]10F. Assertions.  It shall be possible to include assertions in programs. If an assertion  g s Zis false when encountered during execution, it shall raise an exception. It shall also be  g Xpossible to include assertions, such as the expected frequency for selection of a condia * g foXtional path, that cannot be verified. [Note that assertions can be used to aid optimiza s8@ g Ttion and maintenance.] F` h ng cT i l Z10G. Suppressing Exceptions.  It shall be possible during translation to suppress indib i isWvidually the execution time detection of exceptions within a given scope. The language hap i Ushall not guarantee the integrity of the values produced when a suppressed exception p~ i pWoccurs. [Note that suppression of an exception is not an assertion that the corresponde lZH>* fZH$l e pd>.Yan gs ZH>/ nitZHioib@ i suing error will not occur.] for` n nd ZH>1n bZH$l  sd>2]ZH>3 IZHri..ss indi i.` o on911.Representation and Other Translation Time Facilities g` p  i$ q arT11A. Data Representation.  The language shall permit but not require programs to i2 q e Zspecify a single physical representation for the elements of a type. These specifications @ q Wshall be separate from the logical descriptions. Physical representation shall include N q Vobject representation of enumeration elements, order of fields, width of fields, pres\ q Vence of "don't care" fields, positions of word boundaries, and object machine addressj q cc^es. In particular, the facility shall be sufficient to specify the physical representation of x q Vany record whose format is determined by considerations that are entirely external to  q Wthe program, translator, and language. The language and its translators shall not guar q Yantee any particular choice for those aspects of physical representation that are unspeci q pRified by the program. It shall be possible to specify the association of physical @ q prPresources (e.g., interrupts) to program elements (e.g., exceptions or signals). e` r T e s [11C. Translation Time Facilities.  To aid conditional compilation, it shall be possible all s >.Yto interrogate properties that are known during translation including characteristics of d s Xthe object configuration, of function and procedure calling environments, and of actual dr s qVparameters. For example, it shall be possible to determine whether the caller has sup s Wpressed a given exception, the callers optimization criteria, whether an actual paramexte s Uter is a translation time expression, the type of actual generic parameters, and the  @ s Gvalues of constraints characterizing the subtype of actual parameters. epr.` t e  p< u qU11D. Object System Configuration.  The object system configuration must be explic J u prXitly specified in each separately translated unit. Such specifications must include the X u Uobject machine model, the operating system if present, peripheral equipment, and the f u leTdevice configuration, and may include special hardware options and memory size. The int u stTtranslator will use such specifications when generating object code. [Note that proin u d Ugrams that depend on the specific characteristics of the object machine, may be made r u alTmore portable by enclosing those portions in branches of conditionals on the object cr@ u amachine configuration.] ` v t s w siV11E. Interface to Other Languages.  There shall be a machine independent interface  w ziQto other programming languages including assembly languages. Any program element q w emUthat is referenced in both the source language program and foreign code must be idenr@ w n Ztified in the interface. The source language of the foreign code must also be identified. ` x od  y emZ11F. Optimization.  Programs may advise translators on the optimization criteria to be  y l Uused in a scope. It shall be possible in programs to specify whether minimum translas y gUtion costs or minimum execution costs are more important, and whether execution time s* y stVor memory space is to be given preference. All such specifications shall be optional. 8 y bSExcept for the amount of time and space required during execution, approximate val F y tXues beyond the specified precision, the order in which exceptions are detected, and the inT y e Xoccurrence of side effects within an expression, optimization shall not alter the semangrb y Wtics of correct programs, (e.g., the semantics of parameters will be unaffected by the t bp@ y 'choice between open and closed calls). urc~` ~ fo gZH>5 xZH$l  mad>:ril usZH>; rs ZH$im y gr `  e (12.Translation and Library Facilities. s` st r$ o Y12A. Library.  There shall be an easily accessible library of generic definitions and t2 tYseparately translated units. All predefined definitions shall be in the library. Library d@ ciTentries may include those used as input-output packages, common pools of shared decrrN tsVlarations, application oriented software packages, encapsulations, and machine config\ raZuration specifications. The library shall be structured to allow entries to be associated j@ an3with particular applications, projects, and users. x`   X12B. Separately Translated Units.  Separately translated units may be assembled into  [operational systems. It shall be possible for a separately translated unit to reference exim Wported definitions of other units. All language imposed restrictions shall be enforced ili Yacross such interfaces. Separate translation shall not change the semantics of a correct r@ in program. t` t e d X12D. Generic Definitions.  Functions, procedures, types, and encapsulations may have en thTgeneric parameters. Generic parameters shall be instantiated during translation and la onZshall be interpreted in the context of the instantiation. An actual generic parameter may  ThYbe any defined identifier (including those for variables, functions, procedures, processp@ io/es, and types) or the value of any expression.   `  2ZH>=e tZH$l d>> seo feZH>? fitZHll..ctions sed.` ac13.Support for the Language t` ot a$ ofS13A. Defining Documents.  The language shall have a complete and unambiguous ded 2 inWfining document. It should be possible to predict the possible actions of any syntactith@ rsUcally correct program from the language definition. The language documentation shall nN etQinclude the syntax, semantics, and appropriate examples of each built-in and pre\ efRdefined feature. A recommended set of translation diagnostic and warning messages j@ es.shall be included in the language definition. x`  2 Z13B. Standards.  There will be a standard definition of the language. Procedures will  Zbe established for standards control and for certification that translators meet the stan@ dard. `   sS13C. Completeness of Implementations.  Translators shall implement the standard  Ydefinition. Every translator shall be able to process any syntactically correct program. u ZEvery feature that is available to the user shall be defined in the standard, in an acces@ )sible library, or in the source program. n` Th a on\13D. Translator Diagnostics.  Translators shall be responsible for reporting errors that bu Ware detectable during translation and for optimizing object code. Translators shall be g m  Xresponsible for the integrity of object code in affected translation units when any sep. anWarately translated unit is modified, and shall ensure that shared definitions have com< li\patible representations in all translation units. Translators shall do full syntax and type J Uchecking, shall check that all language imposed restrictions are met, and should protX t Uvide warnings where constructs will be dangerous or unusually expensive in execution cf llXand shall attempt to detect exceptions during translation. If the translator determines l t stYthat a call on a routine will not terminate normally, the exception shall be reported as @ *a translation error at the point of call. ` s l r Y13E. Translator Characteristics.  Translators for the language will be written in the i . Slanguage and will be able to produce code for a variety of object machines. The ma co nsSchine independent parts of translators should be separate from code generators. Al, a Ythough it is desirable, translators need not be able to execute on every object machine. a at[The internal characteristics of the translator (i.e., the translation method) shall not be uag@ io3specified by the language definition or standards. e w` tr s o\13F. Restrictions on Translators.  Translators shall fail to translate otherwise correct ns n.Sprograms only when the program requires more resources during translation than are ot  , Wavailable on the host machine or when the program calls for resources that are unavailt o* Xable in the specified object system configuration. Neither the language nor its transla l8 itWtors shall impose arbitrary restrictions on language features. For example, they shall ofF ThUnot impose restrictions on the number of array dimensions, on the number of identifi T@ rsRers, on the length of identifiers, or on the number of nested parentheses levels. b` o cp R13G. Software Tools and Application Packages.  The language should be designed ~ beWto work in conjunction with a variety of useful software tools and application support ZH>ArtiZH$l thed>Ba oremoZH>C ZHla  or when ll  naWpackages. These will be developed as early as possible and will include editors, interthe trXpreters, diagnostic aids, program analyzers, documentation aids, testing aids, software s.$ sZmaintenance tools, optimizers, and application libraries. There will be a consistent user 2 tiZinterface for these tools. Where practical software tools and aids will be written in the @ Slanguage. Support for the design, implementation, distribution, and maintenance of s.N hoYtranslators, software tools and aids, and application libraries will be provided indepena\@ ca1dently of the individual projects that use them. hUU` @  tUU` e HThis document was converted to an electronic format by David A. Wheeler a`  ZH>EZH$l r wd5Leftnad6deRightsd7in Reference,dDtrerdIm erdLtis,dU madXs,ppd[wia d^tidas. pddildg d jr sid mbuand p d se and vbrwidyd|di pdUUd eThdtoecdWhadddd wd a e/@ a Normal. @ b cent1. @ c  Normal. @ d  Normal. f o T   TableTitleT:Table : . f p   CellHeading. f q  CellBody. f r   CellFooting. f s  Body. @ t  Header. @ u  blaFooter. @   RTF_Defaults. @   center. @  cent1. @  para8. @  cent3. >@  para4. @  cent5. @  . para6. @  *. para7. @   center. @  para10. @  . para11. @  .t para12. @  ..a para16. @   center. @  9.t para17. l$ @  l.item. @  para19. @  9. apara21. @  preface. @  para22. @  . para23. @  body. @  *. para24. @  . para26. @  body. @  . para28. @  para31. @  .. para30. l$ @  l.item. @   . 1heading. @   dy. 1heading. @  *. requirement. @  *. requirement. @   *. 2heading. @   *. 2heading.   Emphasis  EquationVariables )   ڝ  ڝ  Default Paragraph Font ڝ  )   [   tu n  Thin Medium gDouble Thick@  Very Thin     oH p q rH p q rH p q rH p q rhH p q rFormat A   oH p q rH p q rH p q rH p q rH p q rFormat B U e W UComment VaHidden d BlackT!WhiteddAReddd Greendd  Blued Cyand Magentad Yellow22221  r0_g0_b128221  r0_g128_b128Th22221  r0_g128_b0221 le r128_g0_b12822221 r128_g0_b0221 r128_g128_b01 r128_g128_b128 r192_g192_b192  Times-Romant Times-Italic Times-BoldHelvetica-BoldTimes Helvetica RegularRegular BoldRegularItalic@dc."%*e=q>=ruF51}Sx ID@}(p;ص(.jW>FdgeD_EAEHo`dILKPp|ɍe745+yrK2|vA&FGIKFK+vz|<{*`Fmq(@ү6##|[Ov j0fRMV{i CaRB~&!|dи ߽E!I@w! #ss8Ujo~ĬO1 gAɮD6\ s-sW֧rhSufViNEM)e[d+Ԕd~?dg!B)13]Zm|@186H & =Fa,Tz?έѢ