;;;-*- Fonts: cthl12, cthl12i, cthl12b, cptfontb, hl10, ct18b, cthl12b, cthl12b, cthl12b, brchars -*-  document interpdebug THE COMPUTER * THOUGHT ADA[ADA IS A REGISTERED TRADEMARK OF THE U.S. GOVERNMENT (ADA JOINT PROGRAM OFFICE).] INTERPRETER/DEBUGGER USER MANUAL INTERPRETER RELEASE V1.0 DEBUGGER RELEASE 1.7 SEPTEMBER 25, 1984 Copyright (C) 1984 Computer * Thought Corporation 1721 West Plano Parkway, Suite 125 Plano, Texas 75075 214-424-3511 NOTICE The software product described herein is the sole and exclusive property of Computer * Thought Corporation. All rights to its use are conditioned upon and granted pursuant to an executed Non-Exclusive System License Agreement (the "Agreement"). The distribution of the software product described herein is intended for the use of the original licensee only and for use on the computer system specified in the Agreement. Lawful users of the software product are licensed only to read the program from its medium into the memory of the specified computer solely for the purpose of executing the program. Copying, duplicating, selling, or otherwise distributing the software product or this operating manual, in whole or in part, in any media is a violation of the law and of the terms and conditions of the Agreement. DISCLAIMER Computer * Thought Corporation makes no representation or warranties with respect to the contents hereof or with respect to the software product described herein and specifically disclaims any implied warranties of merchantability, fitness for any particular purpose, that use of the software product will not infringe any patent, copyright or trademark, or otherwise. Further, Computer * Thought Corporation reserves the right to revise the software product and this operating manual and to make changes from time to time in the content hereof without obligation of Computer * Thought Corporation to notify any person or organization of such revision or changes except as provided in the Agreement. Computer * Thought Corporation shall not be liable for technical or editorial omissions made herein; nor for incidental or consequential damages resulting from the furnishing, performance or use of the software product or this material. Copyright [copyright] 1984 by Computer * Thought Corporation. All rights reserved worldwide.  chapter id-chapter-1 51. Introduction* The Computer * Thought Ada Interpreter/Debugger provides access to the Ada programming language by means of an interpreter and a window-oriented, interactive debugger. These tools have been designed to make Ada easy to learn, and to make Ada programs easy to write and debug. The current release of the Ada Interpreter provides a rich, nearly-complete implementation of the Ada language. Language constructs that will be implemented in future releases are described in the release notes accompanying this manual. The interpreter first translates your Ada program into a special representation, one that meets the needs of both the execution component of the interpreter and the Interactive Debugger. The interpreter then executes your program by processing this internal representation. Your program can be spread out among several Ada source code files and a library file containing "precompiled" Ada code. You can also save precompiled code ( the interpreter's internal representation of your program) in a file for execution at a later time. Through its use of multiple windows, the Interactive Debugger can display your Ada program, your program's input/output history, and diagnostic messages from the debugger itself. You can interrupt your program while it is running, examine the values assigned to variables, and study the runtime context of function and procedure calls and their associated variables. You can also trace function and procedure calls and data structure modifications, and set breakpoints in your program. Since the interpreter's internal representation of your program is closely linked to your program's Ada source code, you can invoke debugger functions on your source code simply by pointing at the desired statement. These high-level techniques should significantly reduce the time needed for you to develop a complete Ada program.  chapter id-chapter-2 52. Document Conventions* The following conventions are used in this manual: - Hyphenated references to keys such as CONTROL-V and META-V mean that two keys are to be pressed simultaneously. (This applies to the #+Symbolics light #+Symbolics beige #+LMI blue keys #+(or LMI Symbolics) with #+(or LMI Symbolics) dark #+(or LMI Symbolics) lettering. #+TI next #+TI to #+the #+space #+TI bar. ) For instance, you can generate CONTROL-V by holding down the first key (CONTROL) and pressing the second key (V). Unhyphenated references to keys such as #=*system-or-select* A mean that keys are to be pressed sequentially. (This applies to the #+Symbolics light #+Symbolics beige #+LMI blue #+TI top #+TI row #+TI of keys #+(or Symbolics LMI) with #+(or Symbolics LMI) white #+(or Symbolics LMI) lettering. #+TI only. ) For example, you can generate #=*function-or-terminal* #=*refresh-or-clear-screen* by pressing first the #=*function-or-terminal* key and then the #=*refresh-or-clear-screen* key. - 3This font will be used to display examples of user input and information printed out by the Interpreter/Debugger.* - 1This italic font will be used to display "placeholder" words in messages and command descriptions -- these are used to describe the kind of data that should be entered or that will be printed. The surrounding text will describe what you will actually see or what you should actually use in place of these words.* - 2This boldface font will be used to display important words and concepts and Ada reserved words.*  chapter id-chapter-3 53. The Computer * Thought Ada Interpreter* This chapter describes the scope of Release v1.0 of the Computer * Thought Ada Interpreter. The Ada Interpreter consists basically of two pieces: - a translator that produces an internal representation of Ada source programs, and - an executor that operates on that internal representation. The current release is a nearly-complete implementation of the Ada language. All the major features of the language are present, including: - attributes - discriminants - exceptions - generics and generic I/O - packages - renaming - tasks and task types Those aspects of the language that will be implemented in future releases are described in the release notes accompanying this manual. A version of this interpreter that covers the entire Ada language will be submitted for Ada Joint Program Office validation. Chapter and section references in this document refer to the Ada Language Reference Manual (LRM).  section id-section3-1 63.1. Interpreter Error Message Classifications* This section describes the kinds of messages generated by C*T's Ada Interpreter when fatal language errors are detected. There are three major classifications of errors that can occur in an Ada program: - 2Lexical errors* are errors in the specification of lexical elements: delimiters, identifiers (including reserved words), numeric literals, character literals, string literals, and comments. For instance, the symbol 312X* contains a lexical error: identifiers cannot start with numbers, and numbers cannot contain the letter 3X*. Section 2.2 of the LRM discusses lexical elements in detail. - 2Syntax errors* occur when a set of legal identifiers are combined in an illegal way. For instance, the following piece of illegal Ada code violates the syntax rules for the Ada 2if* statement, although the individual lexical elements are acceptable: 3 if A > B else A := 0; then B := 0; end if;* - 2Semantic errors* occur when syntactically correct statements are combined in illegal ways. For instance, an Ada program containing the statements: 3 A: integer := 0; B: real := 1.5; ... A := B;* is semantically incorrect. Since 3A* and 3B* are not of the same type, the assignment statement is illegal. All of the interpreter's error messages are displayed in the following format: 3 --------------------------------------------------------------------- | "test.ada", line 25 | Syntax error: | A simple expression was expected in a relational expression. | Description: LRM Section 4.4, Paragraph 2 | Example: LRM Section 4.5.2, Paragraph 11 ---------------------------------------------------------------------* The content of this message is: - 3"test.ada", line 25* The place where the error was detected: line 25 of the file 3test.ada*. Note that the line where the error was 2detected* is not necessarily the line containing the error itself. - 3Syntax error:* The type of error is either 3Lexical*, 3Syntax*, or 3Semantic*. - 3A simple expression was expected in a relational expression.* The interpreter's diagnosis of the error in the flagged statement. - 3Description: LRM Section 4.4, Paragraph 2* The section of the LRM that describes the language violation. - 3Example: LRM Section 4.5.2, Paragraph 11* The section of the LRM containing an example of the correct use of the language construct in question. Not all error messages contain references to examples. Since many error messages are almost identical except for a few words, this listing of messages uses two conventions to minimize the size of this section: - Words or phrases that will be filled in by the interpreter are represented by a phrase in 1italics* that describes the information that will be provided. - Optional phrases are enclosed in [brackets]. Consequently, the description of the error message shown above: 3 A simple expression was expected in a relational expression.* can be found under: 3 An 1Ada construct* was expected [in a 1context*].* where 3simple expression* corresponds to 1Ada construct*, and 3in a relational expression* corresponds to 3in a 1context**.  section id-section3-2 63.2. Interpreter Error Messages* The error messages generated by the interpreter are listed in this section. They are listed in alphabetical order, although the use of italicized phrases to indicate information provided by the interpreter means that a particular message may not appear exactly where it was expected. For example, the message 3An exception was expected* is described by the message 3A 1construct* was expected. A bracket was found where a parenthesis was expected. Description: LRM Section 4.1.1, Paragraph 2 Example: LRM Section 4.1.1, Paragraph 5* A bracket in this expression needs to be changed to a parenthesis. A common cause of this error is the use of brackets around array subscripts: 3 A: ARRAY (1 .. 5) of INTEGER; ... A[1] := 1; A 1character* was probably omitted [in a 1context*].* A non-alphanumeric character was expected, but was not found. This message will generally report the absence of delimiter characters such as colons, semicolons, and commas. The messages may include information about the context in which the error was detected. For example: 3 A semicolon was probably omitted. Description: LRM Section 2.2, Paragraphs 1-9 A colon was probably omitted in an assignment statement. Description: LRM Section 5.2, Paragraph 2 Example: LRM Section 5.2, Paragraph 5 A 1construct* was expected [in a 1context*].* An Ada language construct was expected to be present in the statement under analysis, but was not found. These messages may include information about the context in which the error was detected. For example: 3 A type mark was expected. Description: LRM Section 3.3.2, Paragraphs 2-3 Example: LRM Section 3.3.2, Paragraph 10 An identifier was expected in a type statement. Description: LRM Section 3.3.1, Paragraph 2 Example: LRM Section 3.3.1, Paragraph 7* This message may also appear if the operation being carried out in the referenced statement required an object belonging to some specific semantic category, and the object present in the statement did not belong to this category. For instance, if 3AGE* is an integer variable, the statement 3raise AGE;* would produce this message, since the 2raise* statement requires an argument that is an exception. 3 A numeric literal may not end with a point. Description: LRM Section 2.4.1, Paragraph 2 Example: LRM Section 2.4.1, Paragraph 5* This message diagnoses two errors in the specification of numbers: - the assignment of a real or floating point value to an integer variable, either during initialization or normal use; i.e., 3 AGE : INTEGER := 30.;* - the omission of the fractional part of a real number; i.e., 3 X : FLOAT := 5.;* The source of both of these interpretations is that a number of the form 330.* is not a legal Ada numeric literal -- there must be at least one digit after the number's decimal point. In the second example above, the statement 3 X : FLOAT := 5.0;* would be acceptable. 3 A 'raise' statement without an exception name is only allowed in an exception handler. Description: LRM Section 11.3, Paragraph 3 Example: LRM Section 11.3, Paragraph 4* A 2raise* statement inside an exception handler may omit the name of the exception to be raised; this has the effect of passing the raised exception on to an exception handler higher up in the runtime calling context. However, when a 2raise* statement is used outside of an exception handler, you must state the name of an exception to be raised. The appearance of this message means that you have used the nameless form of the 2raise* statement in some place other than an exception handler. 3 An aggregate for an unconstrained array cannot use the 'others' association. Description: LRM Section 4.3.2, Paragraph 4 Example: LRM Section 4.3.2, Paragraphs 13-16* The reserved word 2others* cannot be used when assigning values to an unconstrained array, because it does not specify a definite range of values. 3 An allocator cannot be assigned to a non-access type object. Description: LRM Section 4.8, Paragraphs 1-2 Example: LRM Section 4.8, Paragraph 14* Allocators can only be assigned to access type objects. The following code fragment would generate this error: 3 subtype INT is INTEGER; type INT_ACCESS is access INT; INT_VALUE : INT; ... INT_VALUE := new INTEGER(1); An error was encountered in a 1context*.* This error message indicates that the interpreter has determined that an error is present, but it cannot additionally determine which particular characters, symbols, words, or Ada constructs are at fault. For example: 3 An error was encountered in a generic specification. Description: LRM Section 12.1, Paragraph 2 Example: LRM Section 12.1, Paragraphs 7-9 An object of one type cannot be renamed with a name of a different, incompatible type. Description: LRM Section 8.5, Paragraph 4 Example: LRM Section 8.5, Paragraph 10* A renamed object must be of the same type as the object being renamed. For example, given the declaration: 3 FLOAT_VAR: FLOAT := 100.0;* the declaration 3 NEW_NAME: INTEGER renames FLOAT_VAR;* would be illegal. 3 An unconstrained array cannot be constrained with an aggregate or a string literal. Description: LRM Section 3.6, Paragraph 5 Example: LRM Section 3.6, Paragraphs 11-13* Consider the following code fragment, in which an unconstrained array is used in an object declaration: 3 type INT_ARRAY is array (INTEGER range <>) of INTEGER; ... MY_ARRAY: INT_ARRAY := (1, 2, 3 => 0);* This declaration is illegal, since the constraints of 3MY_ARRAY* are not provided. A legal version of this statement would be: 3 MY_ARRAY: INT_ARRAY(1 .. 3) := (1, 2, 3 => 0);* This error will also be obtained if an object of type 3STRING* is declared and instantiated without also declaring the size of the string. Ada strings are implemented as arrays of characters, and the pre-defined 3STRING* type is an unconstrained array of characters. For instance, the statement: 3 NAME: STRING := "John";* is incorrect. The correct statement would be: 3 NAME: STRING(1 .. 4) := "John"; An unconstrained array type cannot be used in an array object declaration. Description: LRM Section 3.6, Paragraph 5 Example: LRM Section 3.6, Paragraphs 11-13* Constructions of the following form are illegal: 3 type ALL_AGES is array (INTEGER range <>) of INTEGER; ... GROUP_OF_AGES: ALL_AGES;* 3ALL_AGES* is an unconstrained array. When an object of that type is created, the bounds of the array must be provided as part of the declaration. For instance, the incorrect statement above could have been written correctly as: 3 GROUP_OF_AGES : ALL_AGES(1 .. 10); An underscore in a numeric literal may not appear next to an 'E'. Description: LRM Section 2.4.1, Paragraph 2 Example: LRM Section 2.4.1, Paragraph 5* When an underscore is used in a numeric literal using the exponentiation notation, underscores may not appear immediately adjacent to the 3E* in this literal. Hence, 3123_456E2* is correct, but 3123_456_E2* is not. 3 An underscore is not permitted here. Description: LRM Section 2.4.1, Paragraph 2 Example: LRM Section 2.4.1, Paragraph 5* An underscore has been encountered in some place where underscores are not permitted. 3 An unexpected end of file was encountered.* The interpreter was parsing a compilation unit when the end of the file being analyzed was encountered. You have probably omitted an 2end* statement from a block or a compilation unit earlier in your program. 3 An unexpected end of file was encountered in a string. Description: LRM Section 2.6, Paragraph 6 Example: LRM Section 2.6, Paragraph 6* The interpreter was parsing a string when the end of the program's file was encountered. Since strings cannot be more than one line long (see the message 3Line separators are not allowed in strings*), the error is probably in the last line of your program. 3 Array aggregates cannot use both named and positional associations. Description: LRM Section 4.3.2, Paragraph 3 Example: LRM Section 4.3.2, Paragraphs 13-16* Unlike record aggregates, the entries in array aggregates must be uniform: they must either be all named or all positional (although the 2others* entry may be used with either form of aggregate). Hence, given the array declaration 3 AGG: array (1 .. 5) of INTEGER;* the following aggregates are legal: 3 AGG := (100, 200, 300, others => 999); AGG := (1 => 100, 2 => 200, 3 => 300, others => 999);* However, the following aggregate mixes named and positional entries and is consequently illegal: 3 AGG := (100, 200, 3 => 300, others => 999); Consecutive underscores are not permitted in identifiers. Description: LRM Section 2.3, Paragraphs 2-4* When underscores are used to break up the letters of an identifier into groups, each group must be separated by one and only one underscore. Hence, 3A_LONG_IDENTIFIER* is legal, but 3A___BAD___IDENTIFIER* is not. 3 Consecutive underscores are not permitted in numeric literals. Description: LRM Section 2.4.1, Paragraph 3 Example: LRM Section 2.4.1, Paragraph 5* When underscores are used to break up the digits of a numeric literal into easy to read groups, each group must be separated by one and only one underscore. Hence, 3123_456* is legal, but 3123___456* is not. 3 Discriminants can be provided only for record types. Description: LRM Section 3.7.3, Paragraph 1 Example: LRM Section 3.7.6, Paragraph 11* A discriminant-like form has been used in something other than a record declaration. For example, the declaration 3 type CHARS (CHAR: CHARACTER) is array (1..26) of INTEGER;* illegally tries to use a discriminant in conjunction with an array specification. 3 Identifiers cannot be ended with underscores. Description: LRM Section 2.3, Paragraphs 2-4* The readability of a multi-word identifier can be improved by using underscores to separate the words that comprise the identifier. For instance, the identifier 3SUMOFSQUARES* is easier to read if it is written as 3SUM_OF_SQUARES*. However, these underscores must be surrounded on both sides by other characters. Hence, 3SUM_OF_SQUARES_* would be incorrect. 3 In this numeric literal, an underscore has not been followed by a legal digit. Description: LRM Section 2.4.1, Paragraph 2 Example: LRM Section 2.4.1, Paragraph 5* When an underscore is used in a numeric literal, there must be digits before and after the underscore. Hence, 3123_456* is correct, but 3123_456_* is not. 3 In this renaming operation, the old and new profiles for 1subprogram* do not match. Description: LRM Section 8.5, Paragraph 7 Example: LRM Section 8.5, Paragraphs 10-12* When renaming a subprogram, the old and new subprogram specifications must have the same number of parameters, and the types of the corresponding parameters must match. If the subprogram is a function, the returned types must also match. In this attempt to rename a subprogram, one of these requirements was not met. 3 Index ranges cannot be used to constrain non-array types. Description: LRM Section 3.6.1, Paragraph 1 Example: LRM Section 3.6.1, Paragraph 12* You have tried to constrain a non-array type with an index range, as in: 3 subtype SMALL_INT is INTEGER(1..5);* You may be confusing array notation with range notation. If 3SMALL_INT* should be allowed to take on values from 1 to 5, the following statement is appropriate: 3 subtype SMALL_INT is INTEGER range 1 .. 5; Integers cannot have negative exponents. Description: LRM Section 2.4.1, Paragraph 4 Example: LRM Section 2.4.1, Paragraph 5* An integer with a negative exponent, such as 35E-3*, has been encountered. This is illegal: numbers with negative exponents can be fractional -- 35E-3* = 0.005 -- and integers, by definition, cannot have fractional components. 3 Internal error: the message 1message* is undefined.* This message identifies an error condition in the interpreter, and should never be seen. If it is, please contact the C*T Customer Support Department. 3 It is illegal to have a "use clause" as a context clause without an accompanying "with clause". Description: LRM Section 10.1.1, Paragraphs 2-3 Example: LRM Section 10.1.1, Paragraph 10* A package referred to by a 2use* clause must first be made visible by a corresponding 2with* clause. If this message is obtained, no 2with* clause has been specified for the referenced package. 3 Line separators are not allowed in strings. Description: LRM Section 2.6, Paragraph 6 Example: LRM Section 2.6, Paragraph 6* The interpreter has encountered a string that contains a line separator character, such as a "line feed" or "newline" (14 octal). This is illegal: an Ada string must begin and end on the same line of the program in which it appears. If you want to define a string that is too long to conveniently fit on a single line of your program, use the catenation operator (3&*) to join two shorter strings. If you want to define a string that contains several lines -- perhaps a paragraph of text -- you should join each of the individual lines together, separated by the 3ASCII.CR* and 3ASCII.LF* characters. Example: the statement 3 PUT("First half" & " " & "Second half");* will print: 3 First half Second half* Similarly, the statement 3 PUT("First line" & ASCII.CR & ASCII.LF & "Second line");* will print: 3 First line Second line More than one body has been specified for subprogram 1name*. Description: LRM Section 6.3, Paragraph 3 Example: LRM Section 6.3, Paragraph 8* More than one body for the subprogram 1name* has been declared in the current compilation unit. 3 Named associations cannot precede positional associations in record aggregates. Description: LRM Section 4.3.2, Paragraph 3 Example: LRM Section 4.3.2, Paragraphs 13-16* Unlike array aggregates, record aggregates can contain both positional and named associations. However, in an aggregate specification, all positional associations must be specified before any named associations are specified. The flagged aggregate violates this requirement. For example, given the declarations 3 type PERSON is record AGE: INTEGER; HEIGHT: INTEGER; WEIGHT: INTEGER; end record;* the assignment 3 MARY := PERSON(30, HEIGHT => 65, 115);* is illegal because of the attempt to use a positional association after the named association. This example could be corrected by using a named association to specify the value of 3WEIGHT*: 3 MARY := PERSON(30, HEIGHT => 65, WEIGHT => 115); No more than one type specification can be provided for an incomplete type declaration. Description: LRM Section 3.8.1, Paragraph 3 Example: LRM Section 3.8.1, Paragraph 6* Several possible matching declarations exist for an object that were declared as an incomplete type. For example, in the program fragment: 3 type CELL; ... type CELL is access LINK; ... type CELL is access DOUBLE_LINK;* two specifications are provided for the incomplete type declaration of 3CELL*. 3 One of the expressions specifying the conditions of this conditional statement is not of a boolean type. Description: LRM Section 5.3, Paragraph 2 Example: LRM Section 5.3, Paragraph 5* In a conditional clause, the evaluation of the expression does not return a value whose type is BOOLEAN or is derived from BOOLEAN. For example, in the program fragment: 3 A, B, C, D, E: INTEGER; ... if A * B then C := FUNC(D, E); end if;* The expression 3A * B* produces an integer, and so is not a legal conditional expression. 3 One of the indices in this array aggregate is greater than the upper bound of its array. Description: LRM Section 4.3.2, Paragraph 9 Example: LRM Section 4.3.2, Paragraphs 13-16* When named associations are used to assign values to the elements of an array, an error will occur if any of the indices are greater than the upper bound of the array. For example, in the declaration: 3 A: array (1..5) of INTEGER := (1..5 => 1, 6 => -1000);* the attempt to assign 3A(6)* the value 3-1000* is illegal, because 3A(5)* was defined to be the upper bound of the array. 3 One of the indices in this array aggregate is less than the lower bound of its array. Description: LRM Section 4.3.2, Paragraph 9 Example: LRM Section 4.3.2, Paragraphs 13-16* When named associations are used to assign values to the elements of an array, an error will occur if any of the indices are less than the lower bound of the array (cf. 3One of the indices in this array aggregate is greater than the upper bound of its array*). 3 One of the keywords used in this subprogram call does not match a keyword in the subprogram's definition. Description: LRM Section 6.4, Paragraph 3 Example: LRM Section 6.4, Paragraphs 7-8* A subprogram has been called using keywords to specify the arguments of the subprogram, and (at least) one of the keywords does not match any of the keywords used in the subprogram definition. Check the definition, and correct the erroneous keyword. 3 One of the names in this representation aggregate does not match any name in its enumeration type. Description: LRM Section 13.3, Paragraph 4 Example: LRM Section 13.3, Paragraph 5* One of the names used in a representation aggregate does not match any name in the corresponding enumeration type. The following code fragment would generate this error: 3 type COLORS is (RED, GREEN, BLUE); ... for COLORS use (RED => 1, YELLOW => 2, BLUE => 3); Package bodies may not contain 'return' statements. Description: LRM Section 5.8, Paragraph 3 Example: LRM Section 5.8, Paragraph 7* This package body illegally contains a 2return* statement. 2return* statements are allowed only in functions and procedures. 3 Since this constant is not a deferred constant, it must be initialized when it is declared. Description: LRM Section 7.4, Paragraph 4 Example: LRM Section 7.4, Paragraphs 5-6* A 2deferred constant* is a constant that is declared but not initialized in the visible part of a package declaration. Such a constant must be of a limited private type, and the initialization of the constant's value must be present in either the private part of the package specification or in the package body. For instance, 3PERPEND* is a deferred constant in the code fragment below: 3 package TRIG is type ANGLE is limited private; PERPEND: constant ANGLE; private type ANGLE is FLOAT; PERPEND: constant ANGLE := 90.0; ... end TRIG;* If a constant is declared without initializing it under any other circumstances, this error will be raised. 3 Since this function call does not return an access object, it cannot be assigned a value. Description: LRM Section 5.2, Paragraph 9 Example: LRM Section 5.2, Paragraphs 5-6* Function calls that return access objects can be assigned values; this operation, in effect, specifies the value to which the returned access object points. The following code fragment demonstrates how this can be done: 3 type ACCESS_INT is access INTEGER; ... POINTER : ACCESS_INT; function INNER (ARG1: INTEGER) return ACCESS_INT is begin ... return POINTER; end INNER; ... INNER(1) := 5;* This error would occur if 3INNER* returned a value that was not an access object; e.g.: 3 function INNER (ARG1: INTEGER) return INTEGER is ... Since this variable is of a private type, it cannot be assigned an aggregate value. Description: LRM Section 7.4.2, Paragraphs 1-2 Example: LRM Section 7.4.2, Paragraph 13* Consider the code fragment: 3 package FOOD is type MEAL is private; ... private type FOOD_TYPE is (MEAT, FRUIT, VEGETABLES, BREAD); type MEAL is record SALAD: BOOLEAN := TRUE; MAIN_COURSE: FOOD_TYPE; DESSERT: BOOLEAN := FALSE; end record;* The statement: 3 MEAL: MAIN_COURSE => MEAT;* would be illegal if it appeared outside the private component of package 3FOOD*, since the components of 3MEAL* are private. Note that this statement would be legal if it appeared inside the private component, however. 3 Task bodies may not contain 'return' statements. Description: LRM Section 5.8, Paragraph 3 Example: LRM Section 5.8, Paragraph 7* This task body illegally contains a 2return* statement. 2Return* statements are allowed only in functions and procedures. 3 The actual parameter provided for the generic formal discrete type parameter is not of a discrete type. Description: LRM Section 12.3.3, Paragraph 1* Consider the code fragment: 3 generic procedure HACK (X: ITEM) is ITEM is range (<>); begin ... end HACK; end;* When this generic procedure is instantiated, the type specified in the instantiation must be either an enumeration type or an integer type or subtype. An attempt to instantiate the procedure with some other type, such as 3 procedure FLOATING_HACK is new HACK(FLOAT);* would generate this error. 3 The actual parameter provided for the generic formal fixed type parameter is not of a fixed type. Description: LRM Section 12.3.3, Paragraph 1* Consider the code fragment: 3 generic procedure HACK (X: ITEM) is ITEM is delta <>; begin ... end HACK; end;* When this generic procedure is instantiated, the type specified in the instantiation must be a fixed type or subtype. An attempt to instantiate the procedure with some other type, such as 3 procedure INTEGER_HACK is new HACK(INTEGER);* would generate this error. 3 The actual parameter provided for the generic formal float type is not of a floating-point type. Description: LRM Section 12.3.3, Paragraph 1* Consider the code fragment: 3 generic procedure HACK (X: ITEM) is ITEM is digits <>; begin ... end HACK; end;* When this generic procedure is instantiated, the type specified in the instantiation must be a floating type or subtype. An attempt to instantiate the procedure with some other type, such as 3 procedure INTEGER_HACK is new HACK(INTEGER);* would generate this error. 3 The actual parameter provided for the generic formal integer type parameter is not of an integer type. Description: LRM Section 12.3.3, Paragraph 1* Consider the code fragment: 3 generic procedure HACK (X: ITEM) is ITEM is range <>; begin ... end HACK; end;* When this generic procedure is instantiated, the type specified in the instantiation must be an integer type or subtype. An attempt to instantiate the procedure with some other type, such as 3 procedure FLOAT_HACK is new HACK(FLOAT);* would generate this error. 3 The actual parameter provided for the in out or out formal parameter 1parameter* is not a variable that may be updated. Description: LRM Section 6.2, Paragraphs 4-5 Example: LRM Section 6.2, Paragraph 7* Consider the procedure definition: 3 procedure OLD_P (AGE: in INTEGER; ANSWER: out BOOLEAN) is if AGE > 60 then ANSWER := TRUE; else ANSWER := FALSE; end if;* If a constant or a literal is used for 3ANSWER* in a call to 3OLD_P*, this message will be raised, since the values of constants and literals cannot be changed. 3 The actual parameters of this subprogram do not match any visible definition of the subprogram. Description: LRM Section 6.6, Paragraph 3 Example: LRM Section 6.6, Paragraphs 4-5* No subprogram could be found that (a) had the same name and (b) had the same parameter profile as the subprogram you have called. There are several possible causes for this error: - The subprogram is undefined. - The subprogram is defined, but its definition is not currently visible. - The subprogram is defined and visible, but the parameters in the subprogram call do not match those in the subprogram definition. For instance, you would get this message if you defined a procedure called 3SWAP* that took two integer arguments, but then called 3SWAP* with two floating-point arguments. 3 The aggregate initializing this unconstrained array has not defined the entire array. Description: LRM Section 4.3.2, Paragraph 11 Example: LRM Section 4.3.2, Paragraphs 13-16* If an unconstrained array is assigned a value by means of an aggregate using named associations, the upper and lower bounds of the array will be determined by the most extreme named associations. For example, given the declaration: 3 type UNCONSTRAINED_INTEGERS is array (INTEGER range <>) of INTEGER;* the declaration: 3 SMALL_ARRAY: UNCONSTRAINED_INTEGERS := (1 => 0, 2 => 100, 3 => 50);* will assign to 3SMALL_ARRAY* an array of type 3UNCONSTRAINED_INTEGERS* with lower and upper bounds of 1 and 3, respectively. Consequently, the declaration: 3 SMALL_ARRAY: UNCONSTRAINED_INTEGERS := (1 => 0, 3 => 50);* would raise this error because no value was specified for 3SMALL_ARRAY(2)*. 3 The aggregate on line 1number* cannot be disambiguated. Description: LRM Section 13.3, Paragraph 4 Example: LRM Section 13.3, Paragraph 5* This error will be generated when an object is being declared to be of an unconstrained array type, and there is something wrong with the aggregate used in the initialization of this object. Check the aggregate carefully. 3 The aggregate on line 1number* cannot be normalized. Description: LRM Section 13.3, Paragraph 4 Example: LRM Section 13.3, Paragraph 5* There is something wrong with the referenced aggregate. Check the aggregate carefully. 3 The alleged function designator "/=" does not represent one of the allowable user redefinable operators. Description: LRM Section 6.7, Paragraph 1 Example: LRM Section 6.7, Paragraph 7* The 3/=* operator cannot be explicitly overloaded by a user program. Rather, the meaning of the 3/=* operator is derived from the 3=* operator -- this insures that 3=* and 3/=* are always converse operations. If you want to overload 3/=* for some type, overload 3=* and the system will generate the appropriate semantics for 3/=*. (See also LRM Section 4.5, paragraph 1.) 3 The argument to the attribute 1name* is type-incompatible with the attribute. Description: LRM Annex A* An attribute has been given an argument that is of the wrong type. For example, in the procedure call: 3 PUT_LINE(INTEGER'IMAGE(3.0));* the argument 33.0* is a floating point literal, which is incompatible with the 3INTEGER'IMAGE* attribute. 3 The argument to the short circuit operator in this conditional statement is not a boolean expression. Description: LRM Section 4.5, Paragraph 3 Example: LRM Section 4.5, Paragraph 8* Arguments to short circuit operators -- 2and then* and 2or else* -- must resolve to one of the boolean values TRUE or FALSE. For example, in the code fragment, 3 A, B, C, D, E: INTEGER; ... if A = B and then C + D then E := 0; end if;* the argument of the 2and then* operator, 3C + D*, resolves to an integer, not a boolean value, and so cannot be used as the argument to the 2and then* operator. 3 The ASCII character 1character* cannot appear in a string literal. Description: LRM Section 2.1, Paragraph 2* The flagged string contains a character that is not a member of the legal Ada character set, as described in Section 2.1. If you must include such a character in a string, use the string catenation feature to combine the string with the representation of the character contained in the ASCII package: 3 "This string contains the character " & ASCII.DEL The ASCII character 1character* is incorrectly used in this numeric literal. Description: LRM Section 2.4.2, Paragraph 3 Example: LRM Section 2.4.2, Paragraph 5* There are two ways in which numbers can contain non-numeric characters. A real or floating point number can contain an exponent, denoted by the use of 3E*, as in 31.234E5*. A based number can also use alphabetic characters for digits with values greater than nine. For instance, hexadecimal numbers (base 16) use the characters 3A* through 3F* to denote values from 10 through 15: the decimal number 31 is written in base 16 as 316#1F#*. In the flagged statement, you have used at least one non-numeric character in some other, illegal, way. 3 The ASCII character 1character* is not part of the Ada character set, and may not appear in an Ada program. Description: LRM Section 2.1, Paragraph 2* The interpreter has encountered a character that is not in the character set recognized by Ada. 1Character* is the octal value of the encountered character's ASCII code. If you really need to include a non-alphanumeric character in your program -- perhaps you want to send an ASCII code to an external device -- you should refer to the appropriately-named character in the ASCII package. Example: The statement 3 PUT(DEVICE1, ASCII.DEL);* would write the ASCII code 128 decimal (200 octal) to 3DEVICE1*. 3 The attribute 1attribute* is not currently implemented. Description: LRM Annex A* The specified attribute is not implemented in this release of the interpreter. Those attributes that are not currently implemented are listed in the release notes accompanying this manual. 3 The character literal 1literal* is illegal: a character literal can be made up of only one character. Description: LRM Section 2.5, Paragraph 1 Example: LRM Section 2.5, Paragraph 3* A character literal can be made up of no more than one character; a literal of the form 3'ABC'* is illegal. 3 The characters '1characters*' do not form a legal delimiter. Description: LRM Section 2.2, Paragraphs 5-6 Example: LRM Section 2.2, Paragraphs 5-6* Ada contains some lexical elements that are made up of two characters that ordinarily serve as delimiters. For example, "3--*" introduces a comment, and "3<=*" serves as the 2less than or equal* comparison operator. The set of delimiter characters in your program, printed in the message as 1symbols*, forms a lexical element not recognized by Ada. 3 The closing hash sign (#) of this based number is missing. Description: LRM Section 2.4.2, Paragraph 2 Example: LRM Section 2.4.2, Paragraph 5* A based number is defined by placing a hash sign (3#*) after the base and at the end of the entire number, such as 316#1FFF#*. You have apparently omitted the final hash sign from such a number. 3 The components of this enumeration type must be separated by commas. Description: LRM Section 3.5.1, Paragraph 2 Example: LRM Section 3.5.1, Paragraph 6* The components of an enumeration type must be separated by commas -- simply separating them by spaces is not sufficient. For example, 3 type COLORS is (RED, GREEN, BLUE);* is correct, while 3 type COLORS is (RED GREEN BLUE);* is not. 3 The function being renamed is undeclared or not visible. Description: LRM Section 8.5, Paragraph 7 Example: LRM Section 8.5, Paragraphs 10-12* An attempt to rename a function failed because the function either has not yet been declared or is not visible at its present position in the program. 3 The 'goto 1label*' statement on line 1number* is illegally trying to transfer control into an embedded structure.* The program is attempting to transfer control into a block of statements. This block could be an explicit 2begin...end;* block, or an implicit block such as the statements in the 2then* clause of an 2if...then...end if;* statement, or one of the branches of a 2case* statement. Such transfers are illegal. 3 The 'goto 1label*' statement on line 1number* and the label 1label* are inside different compilation units: transfer of control between compilation units is illegal. Description: LRM Section 5.9, Paragraph 3 Example: LRM Section 5.9, Paragraph 6* A 2goto* statement has tried to jump from one compilation unit into another. The 2goto* statement can only be used to transfer control within a single compilation unit. 3 The identifier 1symbol* is undeclared. Description: LRM Section 8.2, Paragraph 1 Example: LRM Section 8.2, Paragraph 1* The referenced identifier was either never declared, or was declared in a program unit that is not currently visible. 3 The integer codes in this representation aggregate are in the wrong order. Description: LRM Section 13.3, Paragraph 4 Example: LRM Section 13.3, Paragraph 5* In the representation aggregate used to declare an enumeration type, the integer codes used for the aggregate objects must increase in an order corresponding to the order of the objects in the aggregate. Given the type declaration 3 type COLORS is (RED, GREEN, BLUE);* the following representation clause would be incorrect: 3 for COLORS use (RED => 4, GREEN => 5, BLUE => 2);* The values associated with 3RED*, 3GREEN*, and 3BLUE* must be strictly increasing, which is not true in this statement: the value associated with 3BLUE* is less than the value associated with 3GREEN*. The values must instead follow a pattern such as: 3 for COLORS use (RED => 2, GREEN => 4, BLUE => 5); The label 1label* in the 'goto' statement on line 1number* has been used more than once. Description: LRM Section 5.9, Paragraph 1 Example: LRM Section 5.9, Paragraph 6* The label referenced by the 2goto* statement in line 1number* has been used in two different locations. All labels for 2goto* statements must be unique. 3 The label 1label* referenced by the 'goto' statement in line 1number* is not directly in an enclosing construct for the goto. Description: LRM Section 5.9, Paragraph 1 Example: LRM Section 5.9, Paragraph 6* The label referred to by the indicated 2goto* statement is not present in this statement's 2enclosing construct*. This error may simply be caused by omitting or misspelling the label. It may also be caused by your trying to transfer control into a different enclosing construct; for instance, jumping into the body of a 2loop* statement, or the 2then* or 2else* clauses of an 2if* statement. 3 The loop or block named with the simple name 1name* must end with that simple name. Description: LRM Section 5.5, Paragraph 3 Example: LRM Section 5.5, Paragraph 12* If the named form of a loop or block is used, the name must be present in the loop or block's 2end* statement. This error will be generated if the name is omitted from the 2end* statement. 3 The name appearing in this 'use' clause is not the name of a package. Description: LRM Section 8.4, Paragraph 2 Example: LRM Section 8.4, Paragraphs 9-11* 2use* clauses must refer to a known package, as in 3use MY_PACKAGE;* The name used in this 2use* clause is not the name of a defined package. 3 The named association 1symbol* in this subprogram call does not match any parameter in the subprogram's specification. Description: LRM Section 5.2, Paragraph 2 Example: LRM Section 5.2, Paragraph 5* The named association used to supply a parameter to a subprogram does not match any of the subprogram's parameters. For example, given the specification 3 function COMPUTE_MASS (VOLUME: in REAL; DENSITY: in REAL);* the function call 3 COMPUTE_MASS(VOLUME => 100.0, SIZE => 10);* specifies a value for 3SIZE*, which is not a formal parameter of 3COMPUTE_MASS*. 3 The 'others' choice is not allowed in an unconstrained array aggregate. Description: LRM Section 4.3.2, Paragraphs 4-8* An unconstrained array aggregate must explicitly specify all the items in the aggregate; consequently, the 2others* choice is not allowed. The following aggregate is therefore illegal: 3 type NUMBERS is array (INTEGER range <>) of INTEGER; ... procedure FOO (AGG:NUMBERS) is begin ... end FOO; ... FOO ((1,2,3, others => -999)); The operand of this type-conversion operation is type-incompatible with the operation. Description: LRM Section 4.6, Paragraph 3 Example: LRM Section 4.6, Paragraphs 17-20* The desired conversion cannot be carried out; for instance, 3STRING(1)* or 3INTEGER('A')*. 3 The overloaded subprogram [1name* referenced on line 1number*] is ambiguous. Description: LRM Section 6.6, Paragraph 3 Example: LRM Section 6.6, Paragraphs 4-5* In a call to an overloaded procedure or function, it is not possible to determine which version of the subprogram should be activated. For example, given the specifications 3 type NEWINT is new INTEGER; function PROC(X: in INTEGER); function PROC(X: in NEWINT);* the function call 3PROC(3);* would be ambiguous. Since 33* is a valid 3INTEGER* as well as a valid 3NEWINT*, it is unclear which version of 3PROC* should be activated. This error could be corrected by explicitly specifying the type of the argument being passed to 3PROC*: 3PROC(INTEGER(3));* or 3PROC(NEWINT(3)); The parent unit specified in the 'separate' statement for this compilation unit cannot be found. Description: LRM Section 10.2, Paragraphs 5-6 Example: LRM Section 10.2.1, Paragraphs 5-8* The code currently being analyzed is the "separated" part of a compilation unit, and the unit referenced by the 2separate* statement cannot be found. For instance, in the code fragment 3 separate (TRIG_PACKAGE) function SIN (ANG: ANGLE) return FLOAT is ...* the package 3TRIG_PACKAGE* cannot be found. You may have misspelled the name of the compilation unit in either the unit's definition or in the 2separate* statement. 3 The parentheses in this expression are unbalanced. Description: LRM Section 4.4, Paragraph 2 Example: LRM Section 4.4, Paragraph 6* The left and right parentheses that appear in this expression do not match. Check the expression carefully. 3 The pragma 1name* is not currently implemented. Description: LRM Section 2.8, Paragraph 1 Example: LRM Section 2.8, Paragraph 1* The current version of the interpreter does not support the referenced pragma. 3 The procedure being renamed is undeclared or not visible. Description: LRM Section 8.5, Paragraph 7 Example: LRM Section 8.5, Paragraphs 10-12* An attempt to rename a procedure failed because the procedure to be renamed either has not yet been declared or is not visible at its present position in the program. 3 The procedure or entry call to 1name* cannot be used as an expression. Description: LRM Section 4.4, Paragraph 3 Example: LRM Section 4.5, Paragraph 8* While function calls can be used as an expression, as in: 3 VAL := SQRT(SIN(90.0));* procedure and entry calls cannot be used in this way. The following statement is illegal for this reason: 3 PUT_LINE(GET_LINE(READ_ME)); The renaming of array elements of an array (1name*) is not supported.* You cannot rename array elements. For example, the following would be illegal: 3 type NAME is (BOB, CAROL, TED, ALICE, FRED, ETHYL); LIST: array (1 .. 4) of NAME := (BOB, CAROL, TED, ALICE); ... ROBERT: FOO renames LIST(1); The reserved symbol '1symbol*' was expected.* A multi-character Ada reserved symbol -- one of 3.., <>,* and 3>>* -- was expected but was not found. For example: 3 The reserved symbol '..' was expected. Description: LRM Section 3.5, Paragraph 3 Example: LRM Section 3.5.1, Paragraph 6 The reserved word '1word*' was expected [in a 1context*].* One of the Ada reserved words was expected but was not found. These messages may include information about the context in which the error was detected. For example: 3 The reserved word 'separate' expected Description: LRM Section 10.2, Paragraph 2 Example: LRM Section 10.2.1, Paragraphs 5-7 The reserved word 'of' expected in array specification Description: LRM Section 3.6, Paragraph 2 Example: LRM Section 3.6, Paragraphs 11-13 The 'return' statement in this function does not include an expression to be returned as the value of the function. Description: LRM Section 5.8, Paragraph 4 Example: LRM Section 5.8, Paragraph 7* Functions explicitly return values by including an expression as part of the 2return* statement, such as 3return VALUE * 17;* When the 2return* statement is executed, this expression is evaluated and returned as the value of the function. When this error message appears, a function contains a 2return* statement that does not specify such a value. 3 The 'return' statement in this procedure illegally includes an expression to be returned as the 'value' of the procedure. Description: LRM Section 5.8, Paragraph 4 Example: LRM Section 5.8, Paragraph 7* Unlike functions, procedures do not return values. Consequently, a procedure's 2return* statement cannot include an expression -- it must be a simple statement of the form 3return;*. 3 The selected component on line 1number* is unknown. Description: LRM Section 4.3.1, Paragraph 1 Example: LRM Section 4.3.1, Paragraphs 4-6* In the declaration of an object of some record type, one of the components referenced in the initializing aggregate does not correspond to any of that record's components. For instance, the following code fragment would generate this message: 3 type THREE_D is record HIGH: FLOAT; WIDE: FLOAT; DEEP: FLOAT; end record; ... CUBE: THREE_D := (HIGH := 3.0, WIDE := 5.0, DEPTH := 6.0); The separate declaration 1object* cannot be found. Description: LRM Section 10.2, Paragraph 5 Example: LRM Section 10.2.1, Paragraph 2* Ada separate compilation allows a compilation unit to declare that some part of the unit -- specifically, a subprogram specification, a package body, or a task body -- will be defined elsewhere. This technique requires that a 2body stub* be specified where the separated code would ordinarily be found, and the subunit, to be marked with a 2separate* statement denoting where its code is meant to be compiled. These conventions insure that the visibility conditions for the subunit can be correctly determined. This error occurs when the interpreter is analyzing the separate subunit, and is unable to locate the appropriate body stub. 3 The 'size' expression in a length clause must be of an integer type. Description: LRM Section 13.2, Paragraph 5 Example: LRM Section 13.2, Paragraph 16* When specifying a length clause, a type's 3SIZE* attribute must be an integer or an integer subtype. For example, in the code fragment: 3 type BYTE is 0 .. 255; for BYTE'SIZE use 8.0;* the use of 38.0* as 3BYTE'SIZE* would generate this error; the integer value 38* should be used instead. 3 The 'size' expression in a length clause must be static. Description: LRM Section 13.2, Paragraph 5 Example: LRM Section 13.2, Paragraph 16* When specifying a length clause, a type's 3SIZE* attribute must be static. For example, in the code fragment: 3 procedure FAULTY (N : in INTEGER) is ... type BYTE is 0 .. 255; ... for BYTE'SIZE use N;* the value of 3N* is dynamic, and so would generate this error. 3 The 'small' expression in a length clause must be of a real type. Description: LRM Section 13.2, Paragraph 12 Example: LRM Section 13.2, Paragraph 16* When specifying a length clause, a type's 3SMALL* attribute must be a real type or subtype. For example, in the code fragment: 3 type QUARTERS is delta 0.25 range 0.0 .. 100.0; ... for QUARTERS'SMALL use 25;* the use of 325* as 3QUARTERS'SMALL* would generate this error; a real value, such as 30.50* should be used instead. 3 The 'small' expression in a length clause must be static. Description: LRM Section 13.2, Paragraph 12 Example: LRM Section 13.2, Paragraph 16* When specifying a length clause, a type's 3SMALL* attribute must be static. For example, in the code fragment: 3 procedure FAULTY (N : in FLOAT) is ... type QUARTERS is delta 0.25 range 0.0 .. 100.0; ... for QUARTERS'SMALL use N;* the value of 3N* is dynamic, and so would generate this error. 3 The starting and ending bounds of a range specification must be of the same type. Description: LRM Section 3.6.1, Paragraph 4 Example: LRM Section 3.6.1, Paragraphs 12-14* Both bounds of a range of possible values specified for a type must be of the same base type. If 3red* were a member of an enumeration type, the range 31 .. red* would be illegal. 3 The starting name of the program block [-- 1symbol1* --] does not match the name used in the block's 'end' statement -- 1symbol2*. Description: LRM Section 5.6, Paragraph 2 Example: LRM Section 5.6, Paragraph 5* A loop, block or subprogram has been closed with an 2end* statement whose name does not match its beginning name. For example, in the program fragment: 3 SWAP: declare TEMP: INTEGER; begin TEMP := FIRST; FIRST := SECOND; SECOND := TEMP; end SWITCH;* the 2end* statement should refer to 3SWAP*, not 3SWITCH*. 3 The 'storage_size' expression in a length clause must be of an integer type. Description: LRM Section 13.2, Paragraphs 8-10 Example: LRM Section 13.2, Paragraph 16* When specifying a length clause, a type's 3STORAGE_SIZE* attribute must be an integer type or subtype. For example, in the code fragment: 3 task type T is ... for T'STORAGE_SIZE use 256.0;* the use of 3256.0* as 3T'STORAGE_SIZE* would generate this error; the integer value 3256* should be used instead. 3 The subprogram [1name*] is undeclared [or not currently visible, or the actual parameters of the subprogram do not match any visible definition of the subprogram.] Description: LRM Section 8.2, Paragraph 1 Example: LRM Section 8.2, Paragraph 1* The specified subprogram was either never declared, or its declaration is not currently visible. This error may also be raised if a function or procedure is declared for one type but called with an argument of a different type: 3 function FACTORIAL (N: INTEGER) is ... function USER is x: float; begin X := FACTORIAL(3.0); ... end USER;* Another way this error may be raised is when a declared procedure is called as a function (or vice versa): 3 function SIMPLE is ... end SIMPLE; ... function USER is begin SIMPLE; end USER; The 1symbol* argument passed to a subprogram is of a different type than that specified by the subprogram itself. Description: LRM Section 6.4.1, Paragraph 1 Example: LRM Section 6.4.2, Paragraphs 3-4* A procedure or function has been called with a parameter of the wrong type. For example, given the declarations: 3 procedure PROC (PARAM1: in INTEGER; PARAM2: in INTEGER); INT1, INT2: INTEGER; REAL1: REAL;* the procedure call 3 PROC(INT1, REAL1);* illegally attempts to supply a real number as the value of an integer argument. 3 The type of a choice in the named aggregate does not match the type specified in its index list. Description: LRM Section 4.3.2, Paragraphs 1-2 Example: LRM Section 4.3.2, Paragraphs 14-15* The choices used in an aggregate must be of the same type as the values used in the declaration of the original object. This error would be raised by the following code fragment 3 type ONE_TO_TEN is array (1 .. 10) of BOOLEAN; OOPS: ONE_TO_TEN := (RED => FALSE, others => TRUE);* due to the type conflict between the integer range of 3ONE_TO_TEN* and the use of 3RED* in the instantiation of 3OOPS*. 3 The type of 'storage_size' in a length clause must be either an access or a task type. Description: LRM Section 13.2, Paragraphs 8-10 Example: LRM Section 13.2, Paragraph 16* When specifying a length clause, the object whose 3STORAGE_SIZE* is being specified must be either an access or task type. For example, in the code fragment 3 type T is digits 5; ... for T'STORAGE_SIZE use 256;* the use of 3256* as 3T'STORAGE_SIZE* would generate this error; the type of 3T* should have been access or task rather than floating point. 3 The type of this identifier's initializing expression is type-incompatible with the identifier. Description: LRM Section 3.2.1, Paragraph 16 Example: LRM Section 3.2.1, Paragraphs 19-20* An identifier has been initialized with an expression that does not match its declared type. For example: 3 AGE_IN_YEARS: INTEGER := 50.5; The value computed in this assignment statement is type-incompatible with the variable receiving the value. Description: LRM Section 5.2, Paragraph 1 Example: LRM Section 5.2, Paragraph 5* An assignment statement cannot assign a value of one type to a variable of a different type. For example, given the declarations 3 A: integer := 0; B: real := 1.5;* the assignment statement 3 A := B;* illegally attempts to assign a real value to an integer variable. 3 The value computed in this 'return' statement is type-incompatible with the return type specified in the function's specification. Description: LRM Section 5.8, Paragraph 5 Example: LRM Section 5.8, Paragraph 7* The expression returned from a function call is not of the type called for in the function declaration. For example, the function 3 function ESTIMATE_NUMBER_OF_DAYS (DAY: INTEGER; MONTH_NUMBER: INTEGER) return INTEGER is return REAL(MONTH_NUMBER * 30 + DAY); end ESTIMATE_NUMBER_OF_DAYS;* claims to return an integer in its specification, but attempts to return a real number in its body. 3 There is more than one body-less specification for 1object*. Description: LRM Section 6.3, Paragraph 3 Example: LRM Section 6.3, Paragraph 8* More than one body-less specification of a compilation unit or data structure is present. For example, this error would occur as a result of the following specifications: 3 function COMPUTE_AGE_IN_DAYS (BIRTH_DAY: in DATE) return INTEGER; ... function COMPUTE_AGE_IN_DAYS (BIRTH_DAY: in DATE) return INTEGER; ... function COMPUTE_AGE_IN_DAYS (BIRTH_DAY: in DATE) return INTEGER is ... end COMPUTE_AGE_IN_DAYS;* This error is flagged when the multiply-defined function is 2accessed*, not when the multiple specifications are first encountered. 3 There is more than one visible function that matches the rename for 1function name*. Description: LRM Section 8.5, Paragraph 7 Example: LRM Section 8.5, Paragraphs 10-12* This renaming operation failed because there was more than one function whose parameter profile -- the numbers of parameters, the types of the corresponding parameters, and the returned type -- matched the profile specified in the renaming statement. This ambiguity must be removed before renaming will be possible. 3 There is more than one visible procedure that matches the rename for 1procedure name*. Description: LRM Section 8.5, Paragraph 7 Example: LRM Section 8.5, Paragraphs 10-12* This renaming operation failed because there was more than one procedure whose parameter profile -- the numbers of parameters and the types of the corresponding parameters -- matched the profile specified in the renaming statement. This ambiguity must be removed before renaming will be possible. 3 There is no full declaration for the incomplete type 1name*. Description: LRM Section 7.4, Paragraph 4* Although the type 1name* was declared as an incomplete type, the full declaration of the type was never found. Consider the code fragment: 3 type CELL; type LINK is access CELL; type CELL is record VALUE: INTEGER; NEXT: LINK end record;* This error would be obtained if the complete definition of 3CELL* (i.e., 3type CELL is record ...*) had been omitted. 3 There is no generic declaration for this generic object. Description: LRM Section 12, Paragraph 2 Example: LRM Section 12.1, Paragraph 8* This error is raised when a generic instantiation of an unknown or non-generic object is attempted; for instance, when the statement 3 package INT_SORT is new GENERIC_SORT(INTEGER);* is encountered without the generic package 3GENERIC_SORT* having been defined. This error is often due to misspelling the referenced package name in a 2with* clause. 3 There is no package specification for this package body. Description: LRM Section 7.1, Paragraph 1 Example: LRM Section 7.3, Paragraph 5* The package body under analysis does not correspond to any package present in the current scope. This may just be a matter of having misspelled one of the names of the package. A more subtle instance of this error can occur in the use of nested packages: the nesting of the package bodies must correspond to the nesting of the package specifications. For instance, given the specification 3 package ONE is ... package TWO is ... end TWO; end ONE;* the body of package 3TWO* must be within the body of package 3ONE*: 3 package body ONE is ... package body TWO is ... end TWO; end ONE;* This error will be generated if the bodies for packages 3ONE* and 3TWO* are defined at the same level of nesting, as in: 3 package body ONE is ... end ONE; package body TWO is ... end TWO; There is no 'return' statement in the function 1name*. Description: LRM Section 4.8, Paragraphs 1-2 Example: LRM Section 4.8, Paragraph 14* A function must contain a 2return* statement that specifies the value returned by the function; function 1name* did not contain such a statement. 3 There must be at least one parameter inside this subprogram call's parentheses. Description: LRM Section 6.4, Paragraph 2 Example: LRM Section 6.4.2, Paragraphs 3-4* When a procedure or function has been specified with default values for its arguments, these default values are obtained by omitting the parentheses that would ordinarily enclose the parameter list of the procedure or function, not by providing a set of parentheses with nothing inside them. For example, the default number of lines to be skipped by the 3NEW_LINE* function (1) can be obtained by the procedure call 3NEW_LINE;*. Using the form 3NEW_LINE();* would lead to this error. 3 This array aggregate does not define a complete array. Description: LRM Section 4.3.2, Paragraph 11 Example: LRM Section 4.3.2, Paragraphs 13-16* When an aggregate is used to assign values to an array, it must assign a value to every element in the array. This error will occur if an aggregate fails to specify a value for one or more elements. For example, in the declaration 3 A: array (1..5) of INTEGER := (1..2 => 0, 4..5 => 1);* the element 3A(3)* is not assigned a value. 3 This array aggregate is illegally nested. Description: LRM Section 4.3.2, Paragraph 1-2 Example: LRM Section 4.3.2, Paragraphs 13-16* A reference to an array element has included an aggregate in an inappropriate place. For example, given the declaration 3 A: array (1..5) of INTEGER;* the assignment statement 3 A := (1, 3, 5, 7, (1, 2, 3));* would be illegal: the fifth element of the array should be an integer, not an aggregate of integers. 3 This attribute may not be used in a length clause. Description: LRM Section 13.2, Paragraph 3 Example: LRM Section 13.2, Paragraph 16* You have used an attribute other than 3SIZE*, 3STORAGE_SIZE*, and 3SMALL* in a length clause. 3 This compilation unit contains incorrect subprogram calls. Description: LRM Section 6.4, Paragraph 2 Example: LRM Section 6.4, Paragraph 7* There is something wrong with one or more subprogram calls within the current program. For example, the interpreter may have been unable to resolve the name of a subprogram, or could not normalize the arguments of a subprogram. This message will occur at the end of the analysis of a compilation unit; the real source of the error will usually be flagged by another message earlier in the program. 3 This enumeration representation clause has the wrong number of values in its aggregate. Description: LRM Section 13.3, Paragraph 4 Example: LRM Section 13.3, Paragraph 5* The number of items in a representation clause and the number of items in the type declaration of the enumeration type must match. The following code fragment would generate this error: 3 type COLOR is (RED, BLUE, GREEN); ... for COLOR use (RED => 1, BLUE => 3); This numeric literal cannot be interpreted. Description: LRM Section 2.4, Paragraph 2* There is something wrong with this numeric literal. Overflow or underflow may have taken place. Check the literal carefully; it may be helpful to refer to the implementation specifications in Appendix F. 3 This object cannot be assigned a value. Description: LRM Section 6.6, Paragraph 3 Example: LRM Section 6.6, Paragraphs 4-5* The object on the left-hand side (LHS) of an assignment statement is not a variable name that can be assigned a value. The LHS object might be a constant name, an 2in* parameter, or a limited private type, none of which can be assigned a value. 3 This record aggregate does not define a complete record. Description: LRM Section 4.3, Paragraph 6 Example: LRM Section 4.3.1, Paragraphs 4-6* One of a record's aggregates has been omitted from an initialization or assignment statement. This error may occur with either named or positional associations. For example, given the declarations 3 type DATE is record DAY : INTEGER range 1..31; MONTH : MONTH_NAME; YEAR : INTEGER range 0..4000; end record; NEXT_CHRISTMAS: DATE;* the declaration 3 THIS_CHRISTMAS: DATE := (25, DEC);* specifies only two of the three record components. The assignment statement: 3 NEXT_CHRISTMAS := (DAY => 25, MONTH => DEC);* similarly omits one of the components. 3 This subprogram call has failed to specify an argument for the subprogram's 1symbol* parameter. Description: LRM Section 6.4, Paragraph 5 Example: LRM Section 6.4, Paragraph 7* In a subprogram call, no actual argument was supplied for the formal parameter referenced in this message, and the subprogram itself does not specify a default value for this argument. For example, given the specification 3 function COMPUTE_MASS (VOLUME: in REAL; DENSITY: in REAL);* the function call 3 COMPUTE_MASS(VOLUME => 100.0);* fails to specify a value for 3DENSITY*. 3 You cannot take the image attribute of an 1aggregate* Description: LRM Appendix A* You cannot take the image attribute of aggregate, where aggregate is a record or array. For example, the following code would be illegal: 3 type FOO is array (1 .. 10) of INTEGER; begin ... PUT_LINE(INTEGER'IMAGE ((1 .. 10 => 3)));*  chapter id-chapter-4 54. Window Configurations* The Interpreter/Debugger has a number of different subsystems, each of which has a corresponding window configuration. The details of each of the subsystems and its corresponding window configuration will be discussed in later sections; however, a general overview of the various window configurations is presented here. Each Interpreter/Debugger window configuration has four main components: 1. On the left edge of the screen a vertical column provides a 2menu* of commands applicable to the current subsystem. 2. Each window configuration has an 2interaction pane*: a horizontal window used to display various informative messages from the Interpreter/Debugger to the user. The interaction pane is labelled with a title of the form subsytem-name Messages to distinguish it from other panes. The interaction pane will remember the entire history of your session with the Interpreter/Debugger. 3. Along the bottom of the screen is a narrow horizontal line displayed in reverse video. This is the 2mouse documentation line* which displays pertinent information about using the mouse. 4. Finally, there are one or more additional, miscellaneous panes. The content of these panes depends on which Interpreter/Debugger subsystem is currently active. In any case, each is clearly labelled on the screen to indicate its use.  section id-section4-1 64.1. Using the Mouse* You will use the mouse in the Interpreter/Debugger in the same way as it is used elsewhere in the system. To select something with the mouse, roll the mouse on the surface of your desk until its moving cursor is pointing at the desired item, and then press one of the three buttons on the top of the mouse. This is called "clicking on an item." You can examine the mouse documentation line at the bottom of the screen to determine the effect of clicking a particular mouse button.  section id-section4-2 64.2. Menus* The Interpreter/Debugger produces a number of menus from which you can make selections using your mouse.  subsection id-section4-2-1 74.2.1. Single Choice Menus* The simplest kind of menu used by the Interpreter/Debugger is the 2single choice* menu; an example is shown in Figure 4-1. This menu will usually appear directly under the mouse's cursor. As you move the mouse's cursor inside the menu, a box will be drawn around the item to which the cursor is currently pointing. You can select one and only one of the items in this menu -- after you click on one of the items, the menu will disappear, with your choice being returned to the controlling program. A single choice menu will also disappear if you move the mouse's cursor off of the menu; this will usually result in the cancellation of whatever operation was controlling the menu. The exact result of moving the mouse off a particular single choice menu will be described in the discussion of the individual Interpreter/Debugger commands. Figure 4-1: A single choice menu (pointing at 2Current activation to the top*).  subsection id-section4-2-2 74.2.2. Multiple Choice Menus* A second type of menu used by the Interpreter/Debugger is the 2multiple choice* menu; an example is shown in Figure 4-2. As its name implies, you may choose any number of items from a multiple choice menu. You do this by clicking on the desired items; when you have selected an item, it will be displayed in reverse video -- with white characters on a black background. If you click on a selected item, you will "deselect" it: it will again be displayed in "normal video," with black characters on a white background. You can use the mouse to select and deselect items from a multiple choice menu until you have chosen exactly the items you want. Figure 4-2: A multiple choice menu (items 2before* and 2after a write* selected). When you have finished your selection, click on 1Do It* -- this will remove the menu from the display and return the selected items to the controlling program. If you click on 1Abort*, the menu will be removed and its controlling operation will be cancelled in much the same way as if you had moved the mouse away from a single-choice menu. The exact result of clicking on 1Abort* will be described in the discussion of the individual Interpreter/Debugger commands. Some multiple choice menus will appear on your display with an item already selected (i.e., already in reverse video). These are "default" selections, items that are especially likely to be the one you would want to select. If this is the item you want, just click on 1Do It*, and that item will be selected. Otherwise, click on this item to deselect it, and then select the item or items you want.  subsection id-section4-2-3 74.2.3. Command Menus* The final type of menu used by the Interpreter/Debugger is the 2command menu*. A menu of this type is used to control the Debugger, as shown in Figure 4-3. A command menu contains menu items representing the available system commands; you can execute a command by clicking on its name. These menus are permanent parts of the window in which they appear; you can select any command from any menu whenever command selection is permitted. Figure 4-3: Command menus in the Interpreter/Debugger: the mouse's cursor is pointing at BEGIN PROGRAM. An important feature of command menus is their ability to offer on-line documentation. When the mouse cursor is positioned over a command menu item, the 2mouse documentation line* -- the reverse video line at the very bottom of the display -- will show a brief description of the function of that command. You do not have to select an item to view this documentation. As you move the mouse from one item to another, the contents of the documentation line will change to describe the item to which the mouse is currently pointing.  section id-section4-3 64.3. Pop-up Text Entry Windows* There are two kinds of pop-up text entry windows: single-line and multi-line.  subsection id-section4-3-1 74.3.1. Single-Line Text Entry Windows* When using the Interpreter/Debugger, you will occasionally have to enter some text that cannot be selected from a menu. When this is necessary, the Interpreter/Debugger will pop up a small window in which you can enter this text. You simply enter the text you want in the popped up window, and terminate either by pressing the RETURN, END, or LINE key, or by clicking the mouse. If you press one of these keys or click the mouse without any other input, the Interpreter/Debugger will use the default value in effect at that moment. The window will then disappear, and the text you entered will be returned to the controlling program. Figure 4-4 contains an example of a single-line text entry window, created during the execution of the Interpreter/Debugger's FIND STRING command. Figure 4-4: A pop-up text entry window: the text to be found by the FIND STRING command is being entered in the pop-up window.  subsection id-section4-3-2 74.3.2. Multi-Line Text Entry Windows* These windows are similar to single-line text entry windows, except that you may enter more than one line of text (using the RETURN or LINE key to get to the next line). Press the END key to terminate input. This will cause the window to disappear and the input to be returned to the controlling program. Figure 4-5 shows a multi-line pop-up text entry window for entering file specifications to the Translator. Figure 4-5: A pop-up text entry window: A file specification is being entered into the Translator.  section id-section4-4 64.4. Scrolling Panes* Each of the Interpreter/Debugger window configurations contains at least one 2scrolling pane.* A scrolling pane is a combination of a regular pane and a command menu, and is used to view a part of a large "document," one that contains, for instance, an entire file of Ada programs or the entire history of the program you are currently executing. You can use the command menu on the left side of each pane to "scroll" that pane over its document to expose the pages you want to see, and to locate individual strings in the document. You can also save the entire document being viewed through a window pane into a file, for future reference or printout. The commands supported by scrolling panes are described below.  subsection id-section4-4-1 74.4.1. FIRST PAGE* 2Menu item:* 9B* 2Function:* To display the first page of the document. 2Result:* The contents of this pane will be changed to display its first page. 2Problems:* If you are already looking at the first page when you issue a FIRST PAGE command, the display will be unchanged. 2To undo:* Undoing the FIRST PAGE command means that you want to reposition the window to display the page that had been displayed before this command had been entered. This will require some number of NEXT PAGE commands to move forward until the desired page is visible. If you were at or near the last page, it might be easier to move to the last page with the LAST PAGE command, and then back up as necessary with the PREVIOUS PAGE command. The FIND STRING command might also be useful.  subsection id-section4-4-2 74.4.2. PREVIOUS PAGE* 2Menu item:* 9D* 2Function:* To display the previous page of the document. 2Result:* The contents of this pane will be changed, depending on the mouse button you click. A left click will display the previous page of the document. There will be an overlap of two lines in the contents of the two pages: the last two lines of the new display will be the same as the first two lines of the old display. A middle click will display the previous half-page of text (in addition to the first half of the current page). A right click will scroll the display down one line and add the last line of the previous page to the display. 2Problems:* If the window is displaying the beginning of the document when you issue this command, you can't move any further backward. The display will be unchanged. 2To undo:* A NEXT PAGE command will return you to your previous position in the document.  subsection id-section4-4-3 74.4.3. NEXT PAGE* 2Menu item:* 9C* 2Function:* To display the next page of the document. 2Result:* The contents of this pane will be changed, depending on the mouse button you click. A left click will display the next page of the document. There will be an overlap of two lines in the contents of the two pages: the first two lines of the new display will be the same as the last two lines of the old display. A middle click will display the next half-page of text (in addition to the last half of the current page). A right click will scroll the display up one line and add the first line of the next page to the display. 2Problems:* If the window is displaying the last page of the document when you issue this command, you can't move any further forward. The display will not be changed. 2To undo:* A PREVIOUS PAGE command will return you to your previous position in the document.  subsection id-section4-4-4 74.4.4. LAST PAGE* 2Menu item:* 9A* 2Function:* To display the last page of the document. 2Result:* The contents of this pane will be changed to display its last page. 2Problems:* If you are already looking at the last page when you issue a LAST PAGE command, the display will be unchanged. 2To undo:* Undoing the LAST PAGE command means that you want to reposition the window to show the page displayed before the LAST PAGE command had been entered. This will require some number of PREVIOUS PAGE commands to move backward in the file until the desired page is visible. If you were looking at or near the first page, it might be easier to move to the first page with the FIRST PAGE command, and then move forward as necessary with the NEXT PAGE command. The FIND STRING command might also be useful.  subsection id-section4-4-5 74.4.5. FIND (Find String)* 2Menu item:* FIND 2Function:* To locate a string of characters in the document displayed in this pane. 2Result:* A pop-up text entry window will prompt you for the string of characters you want to find; see Figure 4-4. Enter this string, and terminate by either clicking the mouse or pressing the RETURN, END or LINE key. You may enter the string in either upper or lower case -- case is ignored during the search. The string may also contain spaces at any point in the search string -- including the very beginning or very end of the string -- and these spaces will be looked for during in the search. The system will then search forward through the document for this string, starting from the current position of the cursor. The system will reposition the window to display the page containing the next occurrence of the string, with the cursor positioned immediately after that occurrence. 2Problems:* If the string you are searching for can't be found, the message: 3 String not found: 1string-to-be-found** will be written to the window. Remember that the search scans 2forward* for the string, starting at the current cursor position. If you are sure that the string is somewhere in the document, it might be in front of your current position. Try moving to the beginning with the FIRST PAGE command and searching again. 2To undo:* To return to where you were when you gave the FIND STRING command, use the NEXT PAGE and PREVIOUS PAGE commands to reposition yourself.  subsection id-section4-4-6 74.4.6. SAVE (Save Pane)* 2Menu item:* SAVE 2Function:* To save the entire document being viewed through this pane into a disk file for later reference or printout. This file not only includes the page of the document currently visible in the pane, but also all undisplayed pages of that document. 2Result:* A pop-up text entry window will prompt you for the name of the file in which the document should be saved. Type in your response terminated by RETURN, END, LINE or a mouse click. The default directory for the file is displayed. If you specify a different directory as part of this file name, it will become the new default directory for all subsequent saves in the current session. A null string uses the default directory. You can save a document as often as you like during a session, using whatever name or names you choose. Of course, the exact result of saving a document more than once into the same file name will depend upon the characteristics of the host file system, especially whether that file system supports multiple versions of the same file name. 2Problems:* If problems occur during the creation or writing of the output file, the error message 3 Cannot save window to file filename* will be written in the Debugger Messages pane, where filename is the file name you specified. 2To undo:* The only way to reset the default directory into which a file will be saved is to specify a directory path when you are prompted for a file name -- there is no way to automatically go back to a previous default directory. If you do not want to keep a file that was created by this command, you can delete it.  subsection id-section4-4-7 74.4.7. CONTROL-S (Stop Scroll)* 2Command:* CONTROL-S 2Function:* To halt screen display and stop lines from scrolling off the top of the screen. 2Result:* The screen will stop displaying any new characters and the contents of the screen will freeze. This allows you to read or reread information at a more leisurely pace. Note that CONTROL-S is a keyboard command and not a menu item that you can click on. 2Problems:* While this command is in effect, the screen will accept no input except CONTROL-Q, the RESUME SCROLL command. When the keyboard appears to be locked up or malfunctioning, the CONTROL-S sequence will have been typed either accidently or intentionally. Typing CONTROL-Q will resume output in these cases. 2To undo:* To undo this command, type CONTROL-Q (RESUME SCROLL). Screen display will then continue from the point where it was interrupted.  subsection id-section4-4-8 74.4.8. CONTROL-Q (Resume Scroll)* 2Command:* CONTROL-Q 2Function:* To resume output to the screen after it has been halted using , the STOP SCROLL command. 2Result:* New characters will appear starting at the cursor. Text at the top of the screen will disappear from view one line at a time as new lines appear at the bottom. Note that CONTROL-Q is a keyboard command and not a menu item that you can click on. 2To undo:* To undo this command, type CONTROL-S (STOP SCROLL). Output to the screen will stop until CONTROL-Q is typed.  chapter id-chapter-5 55. Running the Computer * Thought Ada Interpreter/Debugger* You can invoke the Interpreter/Debugger with the CTADA function. This function will allow you to specify: - the source code files in which your program is contained - the kind of processing that your program will receive: whether it will be executed or simply analyzed for errors - whether the Interactive Debugger will be invoked on your program - whether a "library file", which contains the internal representation of a set of Ada procedures, should be merged with your source code - whether the translator's analysis of your program will be sent to your terminal or saved in a file - whether the translator's internal representation of your program will be saved for future use as an Ada "library file" After you have specified this information, the execution of your program will begin.  section id-section5-1 65.1. Using the CTADA Function* To use the Interpreter/Debugger, follow these steps: 1. Load a world-load containing the Interpreter/Debugger and log in. 2. Next, enter the CTADA function by typing 3(CTADA)* -- parentheses included -- to any active Lisp Listener.(The use of upper case in this and other examples has no particular significance; your input can be in either upper or lower case.) 3. The CTADA function will create a process running the Ada Interpreter/Debugger and then switch you to that process. You can return to this process at any time by typing SELECT key, where key is the alphabetic letter chosen when the Ada Interpreter/Debugger was installed (usually "A"). 4. You will then be presented with a screen in which you can specify the Ada programs that should be run and the conditions under which they will be run. Your interaction with the Interpreter/Debugger will take place in four subsystems: - In the 2Translator*, you specify what files will be used by the translator, and how the interpreter will use them. - In the 2Checker*, you can analyze your Ada program for syntax and static semantics errors. - In the 2Executor*, you can execute an Ada program for which no errors were detected during a previous translation. - In the 2Debugger*, you can analyze the execution of your Ada program: you can set break points, trace subprogram calls and data structure modifications, and examine the run-time context of your program's execution. These subsystems are constructed so that each is easily accessible from any other. For instance, you can enter the Translator and choose the files you want to execute, move to the Executor to run the program, and move on to the Debugger to determine the cause of an error in the program. You can then return to the Translator to specify a new set of files for execution, and move directly to the Debugger to monitor their execution more closely.  section id-section5-2 65.2. The Translator: Controlling Program Execution* Immediately after calling CTADA, the Translator window will appear (Figure 5-1). In this window, you will specify the files that will be used by the translator and the type of processing that these files will receive. Figure 5-1: The Interpreter/Debugger Translator window  subsection id-section5-2-1 75.2.1. File Specification Pane* The large pane in the center of the screen is used to specify the files that will be used by the translator during program analysis and the interpreter during program execution. The four categories of files -- 2source files, library files, internal files,* and 2listing files* -- are described below. To specify the members of one of these categories of files, click the mouse on the corresponding file label in this pane. For example, if you wanted to specify the Ada source code files to be used in this session, you would click on 3Source files*. A small text input window will then appear in which you should enter the file or files that will make up this category (Figure 5-2). Figure 5-2: Using a text input window to specify source code files These files can be on any host or file server to which your machine has access; their names should of course observe the proper syntax for their hosts. No wild card specifications are supported in any of these categories. You can change the contents of these categories as often as you like, until you move to another subsystem by clicking on the appropriate command in the Translator's command menu. You can also remove all the files from this pane by clicking on the CLEAR item in the command menu; this command can be especially useful when you have already executed one set of files and have returned to this window to specify a completely different set of files for execution (see the discussions of the Executor (Section 5.4) and Debugger (Section 5.5)).  paragraph id-section5-2-1-1 85.2.1.1. SOURCE FILES* 2Function:* 2Source files* contain Ada source code. In this category, you can enter the names of the source code files that make up your program. If more than one file name is entered, the files will be put together in the order specified and processed as if they were a single file. If you do not want to specify any source files, just leave the editing window empty and exit it by typing END. (See the discussion of library files (Section 5.2.1.2) to find out why omitting source files may sometimes be a reasonable thing to do.) 2Restrictions:* If you do not specify a source file, the LIBRARY FILE category must contain a legal library file. 2Problems:* A summary of the errors that can occur during file name specification can be found in Section 5.2.1.6.  paragraph id-section5-2-1-2 85.2.1.2. LIBRARY FILE* 2Function:* 2Library files* contain the translator's internal representation of a collection of Ada compilation units. The most common use of library files is to merge a file containing the "precompiled" forms of some Ada procedures with the source code that you want to execute. You can create such a file by running the translator on the procedures' Ada source code and saving this internal representation as an INTERNAL FILE (see Section 5.2.1.3). If you do not want to specify a library file, just leave this category empty. If you specify a library file but do not specify any source files, the interpreter will assume the library file contains a complete Ada program and will execute it once you enter the Executor or Debugger. This is a good technique to use when you have a program that has been debugged and that must be executed repeatedly: run the program's source code through the translator once and save its representation of the program by specifying a file in the INTERNAL FILE category. This program can then be run repeatedly without the expense of syntax and semantics analysis by (a) not specifying any files in the SOURCE FILES category and (b) entering this file in the LIBRARY FILE category. 2Restrictions:* Only one file can be specified in the LIBRARY FILE category. 2Problems:* A summary of the errors that can occur during file name specification can be found in Section 5.2.1.6.  paragraph id-section5-2-1-3 85.2.1.3. INTERNAL FILE* 2Function:* By specifying a file name in the INTERNAL FILE category, you can save the translator's internal representation of the Ada compilation units being analyzed in this run in a 2library file.* This is an ASCII file whose contents are analogous, but not identical, to the object code files generated by programming language compilers. The internal representations of debugged Ada compilation units can be saved and reused without the need to recompile them before each usage (see Section 5.2.1.2). Each compilation unit whose representation is saved must be a legal Ada compilation unit, but together these units need not form an executable program. They might instead be a set of independent procedures with some common purpose, such as an Ada package of trigonometric functions. If you do not want to specify an internal file, just leave this category empty. 2Restrictions:* Only one file can be specified in the INTERNAL FILE category. If the separate compilation capability of Ada is being used to execute this program, the internal file must contain the parent compilation unit of the program being executed. Internal files will work only with the release of the Interpreter/Debugger with which they were created. When a new release of the Interpreter/Debugger is installed at your site, you will need to recreate your internal files with this new system. 2Problems:* A summary of the errors that can occur during file name specification can be found in Section 5.2.1.6.  paragraph id-section5-2-1-4 85.2.1.4. LISTING FILE* 2Function:* By specifying a file in the LISTING FILE category, you can send the translator's analysis of your program to a 2listing file*. This will result in a complete redirection of the translator's analysis to the named file, except for error messages and the final summary of the number of errors detected in the program, which will be displayed on your terminal. The behavior of the Interpreter/Debugger during execution will not be affected by this option: you will still enter whatever subsystem you choose during execution, and your program's output will still be written to the corresponding window. If you do not want to specify a listing file and wish instead to have all output go to your terminal, just enter a RETURN with nothing else on the line. 2Restrictions:* Only one file can be specified in the LISTING FILE category. 2Problems:* A summary of the errors that can occur during file name specification can be found in Section 5.2.1.6.  paragraph id-section5-2-1-5 85.2.1.5. Examples of File Name Entry* The figures on the following pages illustrate some of the different ways in which files can be specified for the Interpreter/Debugger. - In Figure 5-3, the translator will be invoked on the source code file 3SWITCH.ADA*; after its initial syntactic and semantic analysis, it will be executed along with the already-analyzed code in 3TRIG.INT*. Figure 5-3: Specifying the files to be used by the Interpreter/Debugger: source and library files. - In Figure 5-4, the source code in 3STAT1.ADA* and 3STAT2.ADA* will be merged and run through the translator. The translator's internal representations of this code will be saved in 3STAT.INT*, and the listing of its analysis of the code, including any error messages, will be saved in 3STAT.TXT*. - In Figure 5-5, no source code files have been specified. Instead, the program in the library file 3CONTROL.INT*, which consists of translator internal representations of source code, will be executed.  paragraph id-section5-2-1-6 85.2.1.6. File Specification Errors* A variety of errors can occur while specifying file names. The file specification could be illegal, the file specified might not exist, or it might exist but be protected from you. The Debugger performs file error checking at two different stages: the first stage is when you type in a file name, the second occurs when the translator must access the files. When you type in a file name, there are two messages you can receive: 3 The file filename cannot be read.* or 3 The file filename cannot be written.* The message you receive depends on whether the erroneous file name was to be opened for reading or writing. You should correct this by first checking the correctness of the file name you typed. If it is correct you should check to see that the file actually exists and that you have access to it, then take corrective action as appropriate. At the beginning of the translation phase the specified file names are again checked for correctness, so you can receive either of the two previous messages at this point as well. In addition, the translator also checks to make sure you have specified at least one source file or library file. If you have not, then you will receive the message: 3 You did not specify any source or library files.* Figure 5-4: Specifying the files to be used by the Interpreter/Debugger: two source files, an internal file, and a listing file. Figure 5-5: Specifying the files to be used by the Interpreter/Debugger: a library file only. You can correct this error by going back and specifying one or both: source file(s) or a library file. If you receive any of the three previous error messages the Debugger will issue the message: 3 There are problems with your file specifications. Try again.* and you will not be switched to execution mode.  subsection id-section5-2-2 75.2.2. Execution Mode Command Menu* After you have specified the files to be used by the Interpreter/Debugger, you should select the execution mode you desire from the command menu on the left side of the Translator Pane. The available execution modes are: 2CHECK* The translator will carry out syntax and static semantic checks on the specified program. The Checker screen will appear, and you can examine any errors that occurred. The program will not be executed. 2EXECUTE* The translator will perform syntax and static semantic checks and the interpreter will then execute your program. If a run-time error occurs during execution, your program will be placed in the debugger with the debugger ready to accept commands and with your program ready to be run, just as if you had initially selected the DEBUG option. 2DEBUG* Like the EXECUTE option, the translator will check and compile your program. In addition, you will be placed in the Interactive Debugger (Section 6) after the translator has carried out its syntax and static semantics checks, but before execution is begun. You can then use the debugger to set breakpoints, to trace and inspect data structures, and to begin program execution. The remaining options in the Translator command menu are: 2CLEAR* Remove all file specifications from the four categories in the File Specification Pane. You may then enter new specifications in the way described earlier. 2QUIT SESSION* Leave the Interpreter/Debugger and return to the previous window.  subsection id-section5-2-3 75.2.3. Returning to the Translator* You can return to the Translator from other subsystems such as the Executor and the Debugger, in order to specify a new set of files to be analyzed by the Interpreter/Debugger. When you do this, the files listed in the Translator window will be those that were used in the previous session. You need only change the file specifications that actually need to be changed before selecting the subsystem you want to enter. When you choose a category of file specifications for modification, the text input window that appears will contain the previous set of specifications, which you may edit in any way you choose to create the desired set of file specifications. As usual with text input windows, type END to leave the window and insert the modified file specifications into the Translator. Note that visiting and then leaving the Translator for another subsystem without modifying any of the file specification categories will cause the same set of files to be analyzed and (if the Executor or Debugger was selected) executed.  section id-section5-3 65.3. The Checker: Checking Your Program for Errors* You can enter the Checker from the Translator by clicking on CHECK in the Translator's command menu. When you do this, the translator will begin to check your program for syntax or static semantic errors. The listing of the interpreter's analysis (including error messages) will be written to the large scrolling window in the middle of the Translator window, and any system messages generated by the interpreter will be written to the Translator Messages pane. Figure 5-6: The Checker window When the interpreter's analysis is complete, the Checker window (Figure 5-6) will appear offering four choices in the command menu: 2EXECUTE* Enter the Executor and run your program. 2DEBUG* Enter the Debugger, where you can run and analyze your program. 2TRANSLATE* Return to the Translator, where you can specify a new set of files to be processed by the interpreter. 2QUIT SESSION* Leave the Interpreter/Debugger and return to the previous window. If you select Execute or Debug mode and the Translator detects any Ada translator errors, you will automatically be placed into the Checker so that you may examine them. The Checker mode is also useful for building libraries, when you just want to translate an Ada module into its internal representation and then place it into a library of other precompiled modules. You cannot move to the Executor or Debugger subsystems if your Ada program contains any translator errors.  section id-section5-4 65.4. The Executor: Running Your Program* The Executor will let you run your Ada program. Clicking on the EXECUTE option in one of the other subsystems will first expose the Translator window while your program is being translated, then switch to the Executor window(Any translator errors will cause the Checker window to appear instead.) where your program will begin running immediately -- without requiring you to click on BEGIN PROGRAM to initiate execution. Figure 5-7 shows the Executor after EXECUTE has been selected and the program has been run. Figure 5-7: The Executor window Although entering the Executor results in the execution of your program, the exact behavior of the Executor depends upon the way it is entered: - If you enter the Executor from the Translator, the translator must first carry out the error analysis of your program and translate it into the internal representation used during execution. The translator's listing of this analysis will be written to the large scrolling pane in the center of the screen.[This is true unless you have previously specified a listing file, in which case the analysis will be written to that file instead (although error messages will still appear in the center screen).] Once this analysis is completed, program execution will begin, with all input and output taking place in the labelled Ada Input/Output scrolling pane that contains the translator's listing. - If you enter the Executor from any subsystem other than the Translator, the error analysis and translation stage will have been already carried out. Execution will then begin immediately, with input and output taking place in the Executor's large scrolling pane. In either case, execution can take place only if no syntax or static semantic errors are present in your program. If any errors are encountered you will be moved to the Checker window instead. You can interrupt the execution of your program by typing SUSPEND if the program is waiting for input, or CONTROL-SUSPEND otherwise. You can also use either ABORT or the CONTROL-ABORT key combination to abort the execution of the program, depending on whether or not the running program is in an input wait state. When your program is not running, either because it has finished executing or because it was interrupted as described above, you have five choices, as made available in the Executor's command menu: 2BEGIN PROGRAM* Start execution again from the beginning of the program. The interpreter will begin executing the first parameterless procedure it encounters at the top level of the list of compilation units supplied by the user. 2CONTINUE PROGRAM* If the program was interrupted, continue execution from the point of interruption. Otherwise, start execution from the beginning. 2DEBUG* Enter the Debugger, where you can run and analyze your program. 2TRANSLATE* Return to the Translator, where you can specify a new set of files to be processed by the interpreter. 2QUIT SESSION* Leave the Interpreter/Debugger and return to the previous window.  section id-section5-5 65.5. The Debugger: Debugging Your Program* The Debugger will let you run your program and analyze its behavior by setting break points, tracing subprogram calls and data structure modifications, and examining the run-time context of the program during a break. The capabilities of the Debugger are described in detail in Chapter 6; this discussion is meant to explain how the interface to the Debugger window (Figure 5-8) operates. Figure 5-8: The Debugger window As with the Executor, the exact behavior of the Debugger depends upon how it is entered: - If you enter the Debugger from the Translator, the translator must first carry out the error analysis of your program and translate it into the internal representation used during execution. The translator's listing of this analysis will be written to the large scrolling pane in the center of the screen.[This is true unless you have previously specified a listing file, in which case the analysis will be written to that file instead (although error messages will still appear in the center screen).] When this analysis is completed, messages will be written to the Debugger Messages pane, and all input and output will take place in the large scrolling pane that contains the translator's listing. The Debugger will await the selection of commands from the command menu. - If you enter the Debugger from any subsystem other than the Translator, the error analysis and translation stage will have been already carried out, so you may select Debugger commands immediately. In either case, execution can take place only if no syntax or static semantic errors are present in your program. If any errors are encountered you will be moved to the Checker window instead. While in the Debugger, you can interrupt the execution of your program by typing SUSPEND if the program is waiting for input, or CONTROL-SUSPEND otherwise. You can abort the execution of your program by typing ABORT if the program is waiting for input, or CONTROL-ABORT otherwise. You can then enter Debugger commands, including those that will allow you to move to the Executor or Translator. These commands are described in detail in Chapter 6, but the commands similar to those present in the other subsystems are worth describing here: 2BEGIN PROGRAM* Start execution again from the beginning of the program. The interpreter will begin executing the first parameterless procedure it encounters at the top level of the list of compilation units supplied by the user. 2CONTINUE PROGRAM* If the program was interrupted, continue execution from the point of interruption. Otherwise, start execution from the beginning. 2EXECUTE* Enter the Executor, where you can run your program. The main reason for moving from the Debugger to the Executor is to take advantage of the slightly different window configuration, in which the pane containing the program listing and input/output is somewhat larger than in the Debugger. Your program also executes slightly faster in the Executor than in the Debugger. 2TRANSLATE* Return to the Translator, where you can specify a new set of files to be processed by the translator. 2QUIT SESSION* Leave the Interpreter/Debugger and return to the previous window.  section id-section5-6 65.6. Special Function Keys* Several function keys have special purposes during the execution of the Interpreter/Debugger. Wherever possible, the effects of these keys have been modeled after the corresponding behavior on the host machine: they depend upon the state of the CONTROL and META keys, and whether your Ada program is waiting for input, as described below: 1. If the Ada program is waiting for input, pressing ABORT or SUSPEND will affect your program whether issued by themselves or in conjunction with the CONTROL or META keys. 2. If the Ada program is not waiting for input, pressing ABORT or SUSPEND by themselves will not take effect until the next time your program requests input. However, if you press the ABORT or SUSPEND keys in conjunction with the CONTROL key, the action associated with the ABORT or SUSPEND key will take effect immediately. In other words, the ABORT or SUSPEND key by itself is a synchronous interrupt; it becomes an asynchronous interrupt when issued in conjunction with the CONTROL key. 3. If you have an Ada program running, 2aborting* it at any time will cause the Ada program to cease execution. You will be returned to the Debugger window or Executor window, depending on which mode you were using to run the program. 4. If you have an Ada program running, 2suspending* it at any time will cause the program counter to be frozen at the current position, and you will be returned to the Executor or Debugger window, depending on which mode you were using to run the program. 5. If you do not have an Ada program currently running, trying to abort or suspend execution will cause the Debugger to issue the message: 3 Your Ada program is not active.* Further, the interrupt will be ignored. The Debugger will also ignore a request to suspend a program that is already suspended, or to resume a program that is already running. 6. After you have suspended execution, pressing the RESUME key or clicking on the 3Continue * 3Program* Debugger menu item will resume the execution of your program from where it left off. If instead you issue an ABORT or CONTROL-ABORT, your program's execution will be terminated and you will remain in the Executor or Debugger window. You could restart your program at this point, but only from the beginning. 7. In all cases where it is appropriate, pressing the RESUME key is equivalent to clicking on the 3Continue Program* Debugger menu item. 8. Processing of interrupts that use the META key are confined to the host operating system itself (CTADA does not try to handle these interrupts). META-ABORT or CONTROL-META-ABORT will cause the CTADA process to be reset (as though you were entering the process for the first time). META-SUSPEND and CONTROL-META-SUSPEND will cause the host Lisp debugger to be called. 9. An additional useful special key combination is FUNCTION REFRESH. Issuing this command will cause the Debugger screen to be redrawn completely and hence cleaned up. This is useful in cases where your screen has become cluttered with system messages or messages from users on other host machines.  section id-section5-7 65.7. CTADA Messages* The following messages, listed in alphabetical order, may appear during your use of the Interpreter/Debugger. These messages describe the progress of your program through the system, and diagnose errors in your use of it. 3 A total of 1number* syntax errors and 1number* static semantic errors were detected.* All program listings contain the above messages, citing the number of syntax and static semantic errors detected during the analysis of the program. 3 Code will not be generated for 1file*.* Since fatal errors were found during the analysis of the compilation units in 1file*, the interpreter will not generate internal representations of these compilation units. 3 Computer * Thought Ada (tm): 1interpreter release number* : 1time* 1site information* Line# Ada Source program* The Interpreter/Debugger has begun to analyze your program. 1interpreter release number* is the current release number of the interpreter, 1time* is the time at which this run began, and 1site information* is a brief description of the machine on which you are running, 3 Computer * Thought Ada (tm): 1interpreter release number* : 1time* 1site information* Program execution has begun.* No compilation-time errors were detected in your program; its execution has begun. 1interpreter release number* is the current release number of the interpreter, 1time* is the time at which this run began, and 1site information* is a brief description of the machine on which you are running, 3 Program execution has ended.* Your program has finished execution. This message will appear regardless of how your program terminated. 3 The contents of the library file 1name* appear to have been corrupted. You will probably need to create a new library file from the original Ada source code.* There is something wrong with the contents of this library file. Keep in mind that you cannot change the contents of library files by manually editing them -- if you do, this message is likely to appear, accompanied by the termination of your program. 3 The file 1filename* cannot be read.* Thi mes age ppea s w en a s rce or lib ary file as een pecified in a tex in ut w andsthatsfileadoesrnothexist.ouYou shouldrre-selecththebfilescategory on whichtyoupwereindow, working, and enter the name of an existing file. 3 The file 1filename* cannot be written.* This message appears when an internal or listing file has been specified in a text input window, and that file cannot be created. The file specification probably contains illegal components, such as a syntactically illegal file name, or it may refer to a directory or subdirectory that does not exist. Check the intended file specification carefully, and try again. 3 The file 1filename* does not appear to be a C*T Ada internal file.* The file specified via the LIBRARY FILE option does not contain Ada internal representations; your program will be terminated. See Sections 5.2.1.2 and 5.2.1.3 for more information on library and internal files. 3 The interpreter is unable to begin executing your program. A complete representation of your program could not be constructed.* Something went wrong with the initial analysis of your program. As a result, a complete internal representation of the program could not be built. Check your program for illegal constructs; the error is most probably within two lines (before 2or* after) of the place where the analysis was terminated. 3 The interpreter is unable to finish analyzing your program. This situation is often the result of invalid Ada programs. Please report this behavior to the C*T Customer Support Department.* An error has occurred during the initial analysis of your program. Please notify the C*T Customer Support Department if such errors occur. 3 The interpreter is unable to finish executing your program. Please contact C*T Customer Support Department.* An error has occurred during the execution of your program; this error is probably due to a bug in the C*T Ada interpreter. Please notify the C*T Customer Support Department if such errors occur. 3 The library file 1name* was not created by this version of the C*T Ada interpreter. You must create a new library file from the original Ada source code.* The file specified via the LIBRARY FILE option contains internal code created using a previous release of the Interpreter/Debugger. To use this code that has been "compiled" into this library file, you will have to create a new library file using the corresponding source file(s) and the latest Interpreter/Debugger release. 3 There was no exception handler for 1exception*. Program execution has ended.* The run-time exception cited in this message was raised during execution, and no exception handler was present to handle the exception. Your program has been terminated. 3 Welcome to the C*T Ada Checker on 1site information* * You have entered the Checker (Section 5.3). Here, you can examine the results of the translation of your program. 3 Welcome to the C*T Ada Debugger on 1site information* Preparing program for execution... Preparing program for debugging... * You have entered the debugger (Section 6). Here, you can examine the state of your program during its execution, or move to the Translator. 3 Welcome to the C*T Ada Executor on 1site information* Preparing program for execution... Program execution has begun.* You have entered the Executor (Section 5.4), in which your Ada program will be executed. After your program terminates, you can re-run it or move to the Translator or Debugger for further work. 3 Welcome to the C*T Ada Translator on 1site information* * You have entered the Translator (Section 5.2). Here, you can specify a set of files for processing and execute them via the Executor or the Debugger. 3 You have specified too many files. Only the first one will be used.* The library, internal, and listing file categories may contain only one file. If you specify more than one file for one of these categories, this message will appear. In addition, the first of the files you specified will be entered into the intended category; the other file specifications will be ignored. Before continuing, make sure that this result is correct. 3 Your input was probably not an Ada program. Program execution has ended.* There is something wrong with one of your source code files; the Interpreter/Debugger does not know how to begin processing its contents. This message will be displayed if a source code file does not contain an Ada program. It could also be displayed if you reference a non-existent compilation unit at the very beginning of your program. 3 Your program's analysis has been terminated. The interpreter is unable to continue its analysis.* Something went wrong during the initial analysis of your program, such that this analysis could not be continued. Check your program for illegal constructs; the error is probably within two lines (before 2or* after) of the place where the analysis was terminated. 3 Your program's analysis has been terminated. Too many errors have occurred for the analysis to continue.* The interpreter's analysis of a program is terminated when more than twenty errors occur. You will have to fix the current set of errors and then rerun your program. 3 Your program's execution has been cancelled due to syntax errors. 1or* Your program's execution has been cancelled due to static semantic errors.* If any syntax or static semantic errors were detected during the analysis of your program, it cannot be executed. The above messages report these conditions. 3 Your program's execution has been terminated. Your program probably uses Ada constructs or features that are not now fully supported.* A run-time error has occurred during the execution of your program. This error is probably due to your use of an Ada construct not yet supported by the current release of the interpreter. The release notes accompanying this manual describe these limitations. 3 Your program's execution has been terminated. The error messages above describe the cause of this termination.* This message is sometimes encountered after a run-time error has been reported. Correct the errors identified and rerun your program.  chapter id-chapter-6 56. The Computer * Thought Interactive Debugger* The Computer * Thought Interactive Debugger is a powerful tool to help diagnose your programming errors. If you selected the 3DEBUG* option when you invoked the Interpreter/Debugger, your program will enter the debugger: - before and after program execution, - when a previously set break point is encountered, and - when the SUSPEND key is typed. The debugger uses multiple windows to display your program, the program's input/output history, and the state of the debugger itself. Using the debugger, you can examine data structures, set or clear breakpoints, explore the context in which an error took place, and continue or restart your program. You can do all of this simply by "pointing" to your Ada source code and executing commands selected from the debugger's command menu. When you enter the debugger, your display will be split into three panes and a command menu, as shown in Figure 6-1. All the debugger's commands are present in the command menu on the left side of the debugger window, and can be executed by clicking on the name of the desired command. Remember that if you point the mouse at one of these commands (without clicking on it), a brief description of its function will be displayed in the mouse documentation line at the bottom of the screen. Figure 6-1: The Interactive Debugger window configuration. The Debugger subsystem uses a window configuration consisting of four major panes. 1. Along the left edge of the screen is a vertical command menu pane. This pane is used to select commands for the Debugger to execute. 2. At the top of the right side of the screen is the Ada Program pane. This pane is used to view the source code of your program. It is used in conjunction with some of the Debugger commands to indicate positions in your program that you wish to monitor or describe. It is also used by the Debugger to indicate points of interest in your program; examples include the current point of program execution and the defining occurrence of an identifier. The Ada Program pane is a scrolling window with scrolling commands at its left margin that can be used to view different parts of your program. 3. In the middle of the right side of the screen is the Debugger Messages pane. This pane is used by the Debugger to print informative messages. This pane is a scrolling window and gives you access to the entire history of your debugging session. You may use the scroll commands at its left margin to review earlier parts of your session. 4. On the bottom of the right side of the screen is the Ada Input/Output pane. Your Ada program's input and output will appear in this pane. At the beginning of a debugging session, this pane contains the listing of the translation of your program. The Ada Input/Output pane is a scrolling window and gives you access to the entire history of your debugging session for each execution of your program. You may use the scroll commands at its left margin to review your program's output, or save the output in a disk file for later analysis.  section id-section6-1 66.1. Monitoring and Object Description Commands* These commands allow you to set break and trace points in your program, observe the parameters being passed to and from functions and procedures, detect changes in the contents of data structures, and examine the values of variables. Together, they enable you to monitor the progress of your program in a highly interactive way. The commands to display data structures and set break and trace points require you to specify the Ada construct to which the command should apply, such as the statement or variable you want to monitor. To use these commands, first use the scrolling pane commands (Section 4.4) and the mouse to place the cursor on the appropriate construct in the copy of your program that appears in the Program Pane. Then, select the command you want to execute. Figure 6-2 shows how a program monitor might be set on the function TOMORROW. The Program Pane's cursor has been positioned over the call to TOMORROW, and the mouse is pointing at the MONITOR PROGRAM command. All of the commands described in this section assume that you have properly positioned the cursor before you issue the command. There are a few simple rules that can help you set monitors accurately: - To monitor an assignment statement, point at the 2:=* assignment operator itself. - To monitor a procedure or function call, point between the left parenthesis that starts the procedure's or function's argument list and the end of the statement. If the procedure or function has no parameters, point 2after* the semicolon that ends the statement. - Pay close attention to the message that appears in the Debugger Messages pane after you have selected the MONITOR PROGRAM or MONITOR VALUE command -- this message will tell you something about what you have selected (e.g., 3Setting a program monitor on a function call * 3expression.*). If this message does not seem right, abort the monitor command, reposition the cursor, and re-issue the monitor command. Figure 6-2: Using the MONITOR PROGRAM command to set a monitor on the function call to TOMORROW.  subsection id-section6-1-1 76.1.1. DESCRIBE OBJECT* 2Function:* To describe a program element from within the debugger. 2Result:* The debugger will print, in the Debugger Messages pane, the properties of the program element currently pointed to by the cursor. While this command may be most useful for finding the values of variables, it can also be applied to such identifiers as function and procedure names. The message displayed by this command depends upon the kind of object being described. Variables are described with messages like 3 n is an input parameter with value 5 1 or* i is an iteration variable with value 5* When describing records or arrays, the debugger will prompt you with a series of single choice menus that request more detailed information about the object to be described. For example, if you wanted a description of the record component 3VRECORD.NAME*, you would point to an instance of the record 3VRECORD* and issue the DESCRIBE OBJECT command. The debugger would then respond with the message 3vrecord is a variable with value...* and display the following menu: 3 1 ** 1Refine the record's value or print all of it? 3 Refine All** If you select the default, 2Refine*, the debugger will pop up a second menu showing the components of the aggregate, such as 3 1 Which component?* NAME ADDR SEX AGE* The debugger will ask you to select one of the record fields in the menu. In this case, you would select 3NAME*. The debugger will then print the value of 3VRECORD.NAME*. If you had previously selected 2All*, the debugger would print all the values associated with 3VRECORD*. For arrays, a similar single choice menu will allow you to select whether you want to see the values of some or all of the array's elements. If you want to see only one of the values, you will be prompted to specify the index value of the desired element; this value must lie within the range of values originally declared for that array. When describing a record access type, the debugger will ask whether you wish to select the 2Accessed object* or its 2Accessor*. The use of the 2All* option in this command is limited in the following way. Since there is not enough room on the display to print very large data structures, the part of the data structure actually printed via the 2All* option will be limited to the first ten items in a component of the data structure, and to the first two subcomponents. The remainder of the elements will be represented by ellipses (3...*). For instance, if you asked to print all of a 20 by 20 by 20 integer array, this command would print something like 3 array BIG_ARRAY is ((10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...) (20, 21, 22, 23, 24, 25, 26, 27, 28, 29, ...) ...)* In addition to data structures, other program elements can be described. Examples of other responses to the DESCRIBE OBJECT command include: 3 alphabet is a string literal today is a function 1 is a numeric literal* The DESCRIBE OBJECT command properly resolves scope and visibility questions. For example, if two functions have local variables with identical names, the variable described will be the one pointed to by the cursor. This value may also depend upon your position in the activation stack (see Section 6.3). If, for instance, you want to obtain the value of a variable or parameter in a recursive function, the value will be retrieved from the current activation record. As you move up and down this stack, the value displayed will change to correspond to your new position in the stack. A final important property of the DESCRIBE OBJECT command is that it automatically creates debugger tags for both the object being pointed at and the defining occurrence of this object; the name of the object is used as the label for the tag. These tags can then be accessed with the DISPLAY TAG command. An easy way to find the definition of a procedure is to find a line in your program containing a call to this procedure, use the DESCRIBE OBJECT command on this procedure, and then use the DISPLAY TAG command to move to the definition of the procedure. 2Problems:* If you are pointing at an Ada reserved word or a blank space when you issue the command, the message 3What you are pointing at is not describable* will be written to the Debugger Messages pane. If the debugger can't find a value for a program element in the current activation environment, the debugger will substitute 3*OUT OF SCOPE** in place of a value for that element. This may happen either because the program is not running or because you are in an activation that does not have access to the program element. If you use this command to describe a generic variable that has been instantiated more than once, the value displayed for this variable will be 3*GENERIC AMBIGUITY**. 2To undo:* There is no need to undo this command, since it does not affect the internal state of the debugger or your program -- all it does is print.  subsection id-section6-1-2 76.1.2. MONITOR PROGRAM* 2Function:* To set a break or trace monitor on an Ada statement or declaration. Trace and break monitors can be activated before and/or after the affected statement or declaration is acted upon. Ada programs are traceable to the statement or declaration level only. Whenever a monitored statement is executed, a message containing the type of statement being executed, the type of monitor that was set, and the monitor's tag will be written to the Debugger Messages pane. If a trace monitor was set on this statement, execution will continue after this message is printed. If a break monitor was set, control will return to the debugger. Execution can be resumed with the BEGIN PROGRAM or CONTINUE PROGRAM commands. 2Result:* The effect of the MONITOR PROGRAM command depends upon the values you specify for three options. These options determine when the monitor will be activated and what kind of monitor will be set, and allow you to specify a label that you can use to refer to the monitor at a later time. - 2When should the monitor be activated?* The first option allows you to specify whether the monitor should be activated 2Before* or 2After* the selected statement is executed (or, in the case of a declaration, elaborated). After you issue the MONITOR PROGRAM command, the following multiple choice menu will appear: 3 1 ** 1Monitoring time(s): 3 * Do It 3 * Abort 3 Before execution or elaboration After execution or elaboration** You should then highlight the desired option or options (2Before*, the default choice, will be highlighted initially when the menu pops up). Monitors can be placed both before and after the execution of the statement by highlighting both choices. Select the 1Do It* item when you have made your final selection. - 2What kind of monitor should be set?* The second option allows you to specify whether you want to set a 2Trace* or 2Break* monitor on the selected statement. If you requested a 2Before* monitor in the first menu, the following single choice menu would appear: 3 1 Action for the BEFORE monitor?* Trace Break* You should then point to the desired action, and click the left button of your mouse. The cursor will initially point to 2Trace*, the default action, when this menu pops up. - 2What should the monitor be called?* You will finally be prompted for a tag that will be associated with the monitor being created. This tag can be used later to remove the monitor with the REMOVE MONITOR command or to display the monitored statement in the Program Pane with the DISPLAY TAG command. A pop-up text entry window will appear in which you can enter the tag; the prompt for this tag will be of the form: 3 Name for the TRACE BEFORE monitor?* Enter a character string you want to use for the tag, followed by a RETURN, END, LINE or mouse click. If you terminate without specifying a character string the debugger will generate the name of the tag for you. If you specify a string for this tag, it must not already be in use as the tag for another monitor. Debugger-generated tags take the form 3pm_1xy*_1nn**. The 3pm* stands for "program monitor," 1x* is either 3t* (2trace*) or 3b* (2break*), 1y* is either 3b* (2before*) or 3a* (2after*), and 1nn* is a unique number assigned to the statement being monitored. When this information has been specified, the debugger will print a message such as 3 Program monitor pm_tb_01 of type trace before has been set* in the Debugger Messages pane reporting that the monitor has been set. When your executing program encounters a monitored statement, a message such as 3 * will be written to the Debugger Messages pane stating that the monitor has been activated. If the activated monitor is a break monitor, the message 3* will be written as well, and control will pass to the debugger. These messages appear in the Debugger Messages pane each time the monitored statement is executed. 2Problems:* If the cursor is not positioned over an Ada statement when the MONITOR PROGRAM command is issued, the message 3What you are pointing at is not program monitorable* will be written in the Debugger Messages Pane. If the name you have specified for this monitor has already been assigned to another monitor, the message 3 The tag name 1name* is already in use. Try again.* will be written to the Debugger Messages pane. The window requesting the tag's name will then pop up again; you should enter a new, unique tag name for this monitor. If you try to set a monitor on a part of a generic object when several instantiations of that object exist, the debugger will monitor all the instantiations of that object. This condition will be reported by the message 3There is a generic ambiguity with the program element you have selected. All instantiations will be monitored.* 2To undo:* The REMOVE MONITOR command can be used to remove a monitor from a statement.  subsection id-section6-1-3 76.1.3. MONITOR VALUE* 2Function:* To set a break or trace point on an Ada data structure. Data structure monitors work in much the same way as program monitors. A monitor can be activated whenever the contents of the data structure are initialized or changed. As with statement monitors, either trace or break monitors can be set. Both monitors print a message in the Debugger Messages pane that includes the name of the data structure being monitored, the type of structure being monitored, and the tag. A trace monitor will continue execution after this message is printed, while a break monitor will transfer control to the debugger and await further commands. Data monitors can be activated when the value of the data structure is initialized, as well as before and/or after a new value is assigned to the data structure. If a break monitor is set before an assignment takes place, the data structure will receive its new value only after you issue a CONTINUE PROGRAM command to resume execution. 2Result:* The effect of the MONITOR VALUE command depends upon the values you select for three options. These options determine when the monitor will be activated and what kind of monitor will be set, and allow you to specify a label that you can use to refer to the monitor at a later time. - 2When should the monitor be activated?* The first option allows you to specify whether the monitor should be activated when the data structure is 2created*, or 2before* or 2after* the selected data structure is assigned a value. After you enter the MONITOR VALUE command, the following multiple choice menu will appear: 3 1 Monitoring time(s)?* 1 Do It* 1 Abort* Creation Before a write After a write* You should then highlight the desired option or options (2After*, the default, will initially be highlighted when this menu pops up). You can place monitors at any one, two, or all three of these monitoring times. When you have made your final selection, select the 1Do It* item. - 2What kind of monitor should be set?* The second option allows you to choose whether you want to set a 2trace* or 2break* monitor on the selected data structure. If you requested a 2before* monitor in the first menu, the following single choice menu would appear: 3 1 Action for the BEFORE monitor?* Trace Break* You should then highlight the desired action, and click the left button on your mouse. The cursor will initially be over 2Trace*, the default, when this menu pops up. - 2What should the monitor be called?* You will finally be prompted for a tag that will be associated with the monitor being created. This tag can be used later to remove the monitor with the REMOVE MONITOR command or to display the monitored value in the Program Pane with the DISPLAY TAG command. A pop-up text entry window will appear in which you can enter this tag; the prompt for this tag will be of the form: 3 Name for the TRACE BEFORE monitor?* Enter a character string you want to use for the tag, followed by a RETURN, END, LINE or mouse click. If you terminate without specifying a character string the debugger will generate the name of the tag for you. If you specify a string for this tag, it must not already be in use as the tag for another monitor. Debugger-generated tags take the form 3vm_1xy*_1nn**. The 3vm* stands for "value monitor," 1x* is either 3t* (2trace*) or 3b* (2break*), 1y* is either 3b* (2before*) or 3a* (2after*), and 1nn* is a unique number assigned to the value being monitored. When this information has been specified, the debugger will print a message such as 3 Value monitor vm_bi_14 of type break creation has been set* in the Debugger Messages pane reporting that the monitor has been set. When your executing program encounters the variable being monitored, a message such as 3 * will be written to the Debugger Messages pane stating that the monitor has been activated. If the activated monitor is a 2before a write* or 2after a write* monitor, the message 3 <1variable-name* is a 1type-of-variable* with value 1value-of-variable*>* will also be written to the Debugger Messages pane. If the activated monitor is a break monitor, the message 3* will be written as well, and control will pass to the debugger. These messages will be written to the Debugger Messages pane each time the monitored variable receives a new value. 2Problems:* If the cursor was not positioned over a data structure when the MONITOR VALUE command was issued, the message 3What you are pointing at is not value monitorable* will be printed in the Debugger Messages pane. If the name you have specified for this monitor has already been assigned to another monitor, the message 3 The tag name 1name* is already in use. Try again.* will be written to the Debugger Messages window. The window requesting the tag's name will pop up again; you should enter a new, unique tag name for this monitor. If you try to set a monitor on a variable inside a generic object when several instantiations of that object exist, the debugger will monitor all the instantiations of that variable. This condition will be reported by the message 3There is a generic ambiguity with the program element you have selected. All instantiations will be monitored.* will be written to the Debugger Messages Pane. 2To undo:* The REMOVE MONITOR command can be used to remove a monitor from a data structure.  subsection id-section6-1-4 76.1.4. REMOVE MONITOR* 2Function:* To remove one or more program or value monitors. 2Result:* A multiple choice menu will appear in the Program Pane listing the tags for all the monitored statements and data structures. The option 3all* also appears as the last option in this menu. Highlight the monitors you want to remove, and then click on 1Do It*. If you select the menu entry for 2all* you will remove all monitors in effect. A message confirming this removal will be written into the Debugger Messages pane. 2To undo:* Monitors can be replaced by re-issuing the relevant MONITOR PROGRAM or MONITOR VALUE command.  section id-section6-2 66.2. Program Execution Commands* These commands control program execution; they allow you to either begin the execution of a program or continue the execution of a suspended program.  subsection id-section6-2-1 76.2.1. BEGIN PROGRAM* 2Function:* To start the execution of your program. 2Result:* The interpreter will begin executing the first parameterless procedure it encounters at the top level of the list of compilation units supplied by the user. Input and output will take place in the Ada Input/ Output pane. The message 3Program execution has begun* will be written to the Debugger Messages pane, confirming the execution of this command. 2To undo:* By typing the SUSPEND key, you can temporarily suspend execution of your program. By typing the ABORT key, you can abort execution of your program. In either case, you will be returned to a point where you can issue debugger commands.  subsection id-section6-2-2 76.2.2. SINGLE STEP* 2Function:* To execute your program one statement at a time. You are returned to the debugger after each execution step, allowing you to use other debugger commands to examine the result of the computation just completed. The components of a complex statement can be executed individually or all at once. 2Result:* Recall that, when you enter the debugger, the Program Pane's cursor is positioned over the beginning of the next statement. When you click on the SINGLE STEP command, a message identifying this statement will be written to the Debugger Messages pane, such as 3 Stepping a type statement. * This statement will then be executed, and you will be returned to the debugger, with the cursor positioned over the beginning of the next statement to be executed. You can execute just this statement by selecting the SINGLE STEP command, or you can resume "full speed" execution by selecting either the BEGIN PROGRAM or CONTINUE PROGRAM command. If the statement you are stepping through contains nested statements or clauses, a single choice menu will pop up, asking whether you want to execute the 2Whole* complex statement or single-step through the individual 2Parts* of the statement. For example, if you reached an 2if* statement, the menu would ask: 3 1 ** 1If statement: Step as a whole or part? 3 Whole Parts** Based on your choice, single-step execution of the complex statement would take place in individual steps or in a single step. If you start the execution of your program from the beginning with the SINGLE STEP command, you will get the following message: 3 Stepping program set up. * Otherwise, the SINGLE STEP command will function as described above. 2To undo:* You can get back to a previously executed statement by restarting the program using the BEGIN PROGRAM command. If you want to interrupt your program at the same place several times during execution, you should set a break point on the appropriate program statement (see Section 6.1).  subsection id-section6-2-3 76.2.3. CONTINUE PROGRAM* 2Command:* CONTINUE PROGRAM or RESUME key 2Function:* To continue the execution of your program from the point where it entered the debugger as the result of a break point or a manual program interrupt via the SUSPEND key. 2Result:* Your program will start to run again, starting at the point of interruption. Input and output will take place in the Ada Input/Output pane. The message 3Program execution has continued* will be written to the Debugger Messages pane, confirming the restarting of your program. 2To undo:* Once you have issued this command, you can only return to the point where you restarted the program by beginning the program over again using the BEGIN PROGRAM command and then suspending it at the same point as before.  subsection id-section6-2-4 76.2.4. SUSPEND (Suspend Program)* 2Command:* SUSPEND key 2Function:* To interrupt the execution of a running program and place the program in the Interactive Debugger at the point of interruption. 2Result:* The message 3* will be written to the Debugger Messages pane. In the Program Pane, the cursor will be positioned over the statement that was being processed at the point of interruption. The debugger will now accept commands. 2Problems:* The debugger is designed to allow you to display and monitor code that you have written. However, if you interrupt your program while the interpreter is executing a hidden function contained in one of its own predefined environment files (such as an input/output package), the cursor cannot move to point to the portion of your code that was executing. Instead, the message 3The tag current pc is in an unviewable file and cannot be displayed* will be written to the Debugger Messages pane. The SUSPEND key has no effect when your Ada program is not running. Section 5.6 describes the use of the ABORT, RESUME, and SUSPEND keys at those times in detail. 2To undo:* To restart the program from the point of interruption, use CONTINUE PROGRAM. BEGIN PROGRAM will resume execution from the beginning of the program.  subsection id-section6-2-5 76.2.5. ABORT (Abort Program)* 2Command:* ABORT key 2Function:* To terminate the execution of a running program. 2Result:* Program execution will terminate and you will be placed in the Interactive Debugger. The debugger will now accept commands. 2Problems:* The ABORT key has no effect when your Ada program is not running. Section 5.6 describes the use of the ABORT, RESUME, and SUSPEND keys at those times in detail. 2To undo:* BEGIN PROGRAM will resume execution from the beginning of the program.  section id-section6-3 66.3. Activation Record Stack Commands* Like programs written in most computer languages, Ada programs are generally made up of a large number of functions and procedures that call each other. When a runtime error occurs, there will usually be a "stack" of function and procedure calls leading up to that error: perhaps function FIRST called procedure SECOND, and procedure SECOND called function THIRD, where the error occurred. What can make debugging computer programs difficult is that, even though the error that stopped the program occurred in function THIRD, the real source of the error might lie in function FIRST -- perhaps one of function FIRST's local variables was initialized incorrectly, and the observed error was really caused by this incorrect value being passed to THIRD. The Interactive Debugger allows you to explore this runtime calling history of your Ada programs while they are executing. This history is represented as a "stack" of 2activation records*, which are structures that correspond to each of the subprogram calls leading up to the error. In the above example, the stack would contain activation records for function FIRST, procedure SECOND, and function THIRD; the record for the "oldest" function in the calling history, function FIRST, would be at the "bottom" of the stack, and the record for the "newest" function in the calling history, function THIRD, would be at the "top." The debugger has a set of commands that allows you to move up and down this stack. As you do so, a description of the activation record you have moved to will be printed in the Debugger Messages pane. This description includes the name of the corresponding function and the names and values of that function's parameters and local variables. Moving through the stack and examining these values is a good way to isolate the real source of a program error. A second reason you might want to use the activation record commands is to inspect program elements using the DESCRIBE OBJECT command. Suppose that you have written a recursive function and an error occurs on the fifth recursive call to the function. If you examine the stack of activation records at the point of this error, you will see that there is one activation record for each call to the function and that you are currently positioned at the "top" of this stack of records. If you use the DESCRIBE OBJECT command to point at parts of this function in the Program Pane and display the values of data structures, the values you see will depend upon your position in this stack of activation records. As you move up and down the stack from one call to the next, you will change the context used to determine the values of data structures, and the values printed for these structures will change correspondingly. This will enable you to track down an error in one of a potentially large number of calls to the same function. A final point: changing your position in the stack of activation records will not affect the point where your program will be resumed should you issue a CONTINUE PROGRAM command -- your program will always resume at exactly the point where it was interrupted.  subsection id-section6-3-1 76.3.1. SHOW ACTIVATION RECORD* 2Function:* To display the contents of the current stack of activation records. 2Result:* The following single choice menu will appear, in which you select how much of the stack you want to be displayed: 3 1 ** 1How much of the stack?: 3 Current activation Current activation to the top Current activation to the bottom All activations** You can request just the 2current* record, all records from the current record 2up* to the top of the stack, all records from the current record 2down* to the bottom of the stack, or 2all* the activations in the stack. The name of the function or procedure corresponding to each requested activation record will then be written to the Debugger Messages pane (along with the names and values of its local variables and parameters if you selected 2current activation*). Three special symbols along the left margin are used to mark important features of the stack. The top and bottom records of the stack are marked with the symbols 3T* and 3B*, respectively. The symbol 3-->* indicates your current position in the stack. This will generally be the top of the stack, but you can change your position with the UP ACTIVATION RECORD and DOWN ACTIVATION RECORD commands. If you had asked to view the records from the current record up to the top of the stack, the display would look something like the following: 3 3 factorial is a function with local variables T--> 4 factorial is a function with local variables* In this example, a recursive function has called itself twice. The numbers 3 and 4 identify the nesting levels, and 3T-->* indicates that you are currently positioned at the top of the stack. If you ask to see all the records on the stack, the display would look something like the following: 3 B 0 *** is an Ada program 1 recfact is a procedure 2 factorial is a function 3 factorial is a function T--> 4 factorial is a function* Note the use of 3**** at the bottom of the stack to represent the outermost Ada environment; this is the basic environment in which all your compilation units are defined. 2Problems:* If you enter this command before your program has begun executing or after it completes execution, the message 3There is no stack* will be displayed in the Debugger Messages pane. 2To undo:* There is no need to undo this command, since it does not affect the internal state of the debugger or your program -- all it does is print.  subsection id-section6-3-2 76.3.2. TOP OF ACT RECORDS* 2Function:* To move to the top of the stack of activation records (that is, the record corresponding to the point where your program was interrupted). 2Result:* The name of the function or procedure corresponding to this activation record will be printed in the Debugger Messages pane, along with the names and values of its local variables and parameters. 2Problems:* If you are already at the top of the stack, your position in the stack will not be changed. The top record will be displayed or remain displayed, with the indicator 3T-->* marking your position in the stack. If you enter this command before your program has begun executing or after it completes execution, the message 3There is no stack* will be displayed in the Debugger Messages pane. 2To undo:* One way to move back to your previous position in the activation record stack is to use the DOWN ACTIVATION RECORD command. Depending on where you were, it might be easier to jump down to the bottom of the stack with the BOTTOM OF ACT RECORDS command and move back up with the UP ACTIVATION RECORD command. The SHOW ACTIVATION RECORD command will probably be helpful in determining how many records to jump over.  subsection id-section6-3-3 76.3.3. UP ACTIVATION RECORD* 2Function:* To move up in the stack of activation records (that is, closer to the activation record corresponding to the most recent function call in your program). 2Result:* You will be prompted in a pop-up text entry window for the number of steps you wish to move up: 3 How many steps up (0 to positive): [1]* Enter this number and type RETURN (the default is one if you do not specify a number and just type RETURN). Your position in the stack will be set to the corresponding activation record, and the contents of this record will be printed in the Debugger Messages pane. 2Problems:* If you are already at the top of the stack, your position in the stack will not be changed. The top record will be displayed flagged with the indicator 3T-->*. If you ask to move up more stack records than are present on the stack, the debugger will move up as many records as it can and display your new position, the top record. If you enter this command before your program has begun executing or after it completes execution, the message 3There is no stack* will be displayed in the Debugger Messages pane. 2To undo:* Use the DOWN ACTIVATION RECORD command to move back to your previous position in the stack. The SHOW ACTIVATION RECORD command will probably be helpful in determining how many records to jump over.  subsection id-section6-3-4 76.3.4. DOWN ACTIVATION RECORD* 2Function:* To move down in the stack of activation records (that is, further from the activation record corresponding to your program's point of interruption). 2Result:* You will be prompted in a pop-up text entry window for the number of steps you wish to move down: 3 How many steps down (0 to positive): [1]* Enter this number and type RETURN (the default is one if you do not specify a number and just type RETURN). Your position in the stack will be set to the corresponding activation record, and the contents of this record will be printed in the Debugger Messages pane. 2Problems:* If you are already at the bottom of the stack, your position in the stack will not be changed. The bottom record will be displayed or remain displayed, flagged with the indicator 3B-->*. If you ask to move down more stack records than are present on the stack, the debugger will move down as many records as it can and display your new position, the bottom record. If you enter this command before your program has begun executing or after it completes execution, the message 3There is no stack* will be displayed in the Debugger Messages pane. 2To undo:* Use the UP ACTIVATION RECORD command to move back to your previous position in the stack. The SHOW ACTIVATION RECORD command will probably be helpful in determining how many records to jump over.  subsection id-section6-3-5 76.3.5. BOTTOM OF ACT RECORDS* 2Function:* To move to the bottom of the stack of activation records (that is, the record corresponding to the function call that started your program). 2Result:* The name of the function or procedure corresponding to this activation record will be printed in the Debugger Messages pane, along with the names and values of its local variables and parameters. 2Problems:* If you are already at the bottom of the stack, your position in the stack will not be changed. The bottom record will be displayed, with the indicator 3B-->* marking your position in the stack. If you enter this command before your program has begun executing or after it completes execution, the message 3There is no stack* will be displayed in the Debugger Messages pane. 2To undo:* One way to move back to your previous position in the activation record stack is to use the UP ACTIVATION RECORD command. Depending on where you were, it might be easier to jump up to the top of the stack with the TOP OF ACT RECORDS command and move down with the DOWN ACTIVATION RECORD command. The SHOW ACTIVATION RECORD command will probably be helpful in determining how many records to jump over.  section id-section6-4 66.4. Task Selection Commands* This set of commands allows you to display the set of tasks in your program and select a particular task for consideration.  subsection id-section6-4-1 76.4.1. SHOW TASKS* 2Function:* To display an ordered list of all the tasks in your program showing task subordination and hierarchical relationships. 2Result:* A printout similar to the following will appear in the Debugger Messages pane: 3 *MAIN*PROGRAM*, priority = 10, runnable * --> GET_MEAT, priority = 10, runnable GET_VEGETABLES, priority = 10, terminated GET_DESSERT, priority = 10, runnable* 3*MAIN*PROGRAM** represents the top-level procedure in which the tasks were created, the asterisk (3**) appears beside the task that was executing when program execution was suspended, and the arrow (3-->*) indicates the currently selected task. If you have selected a particular task for consideration using the CHOOSE TASK command, the arrow may be pointing to a different task from the one flagged with an asterisk. 2Problems:* If the program has not yet started or has already finished execution, the message 3There are no tasks* will be displayed in the Debugger Messages pane. 2To undo:* There is no need to undo this command, since it does not affect the internal state of the debugger or your program -- all it does is print.  subsection id-section6-4-2 76.4.2. CHOOSE TASK* 2Function:* To select a particular task for examination. Each task has its own set of activation records associated with it. The CHOOSE TASK command determines which set of activation records will be displayed by the activation record commands and used by the DESCRIBE OBJECT command. When you click on this command, a single choice menu will appear listing the names of all the active task bodies in your program, and also the tag 3*MAIN*PROGRAM**, which represents your top-level procedure. Select the task you want to examine from this menu. 2Result:* The cursor in the Program Pane will be positioned over the selected task at the point where the task was executing when you issued this command, and a message similar to the following will appear in the Debugger Messages pane: 3 Task GET_DESSERT has been selected.* When you issue the SHOW TASKS command, the arrow will now be pointing to the selected task in the Debugger Messages pane. Since each task has its own set of activation records and variables, issuing this command affects the results you receive when you move up and down the stack of activation records examining various values (see Section 6.3 as well as Section 6.1.1 on describing objects). This command does 2not* affect the point at which program execution will resume -- execution will always resume at the exact point of interruption. 2Problems:* If your program has not yet started or has already finished execution, the message 3There are no tasks* will be displayed in the Debugger Messages pane. 2To undo:* If you want to return to analyzing a previously analyzed task, reissue this command and select that task from the menu. Remember that the task that was running when the debugger was entered is marked by an asterisk in the SHOW TASKS command.  section id-section6-5 66.5. Other Debugger Commands* A final set of commands allows you to carry out an assortment of activities related to debugging your program. These include choosing a file for viewing in the Program Pane, displaying the current state of the debugger, and displaying a tagged portion of your program.  subsection id-section6-5-1 76.5.1. CHOOSE FILE* 2Function:* To select a file for viewing in the Program Pane. 2Result:* A single choice menu will appear, containing the names of the source and library files you specified previously. The menu will also include the interpreter's standard environment files (such as TEXT_IO and SEQUENTIAL_IO) that may be used in conjunction with your program; source code, library, and environment files will be marked in this menu with 3*, 3*, and 3*, respectively. Select the desired file with the mouse. If you have viewed the specified file before, the point where you were before will be displayed. Otherwise, the first page of the specified file will be displayed in the Program Pane. Only the standard environment files and those files that you specified when you invoked the Interpreter/Debugger can be selected and examined in the debugger. 2To undo:* Undoing the CHOOSE FILE command means that you want to return to viewing the file that had been displayed before you executed this command. To do this, just re-execute the CHOOSE FILE command, and select the file that had been displayed previously.  subsection id-section6-5-2 76.5.2. DISPLAY TAG* 2Function:* To display the code corresponding to a previously-tagged monitor, program element or program counter position. 2Result:* A single choice menu will appear, containing several tag names. Select the desired tag with the mouse. The contents of the Program Pane will then be changed to display the point in your program corresponding to this tag. In this menu, the cursor will initially be pointing at 2True PC*, the default, when the menu first appears. The tags presented in this menu fall into three classes: - 2Program counter tags.* These tags are related to the "program counter" -- the piece of your program that was being executed at the time the debugger was entered: 3 1 ** 1Which tag? 3 True PC Current PC Top of activation Bottom of activation** * 3True PC* points to the part of the program that was actually being executed when the debugger was entered. If you restart this program with the CONTINUE PROGRAM or SINGLE STEP commands, it will resume from this point. * When you first enter the debugger, 3True PC* and 3Current PC* will both point to the same place. However, if you change your position in the stack of activation records with such commands as DOWN ACTIVATION RECORD, 3Current PC* will point to the statement in that activation record that was being executed when the next activation was entered. * 3Top of activation* points to the beginning of the block of source code corresponding to the current activation record, and * 3Bottom of activation* refers to the end of the block of source code corresponding to the current activation record. See Section 6.3 for more information about activation records. - 2Described objects.* These tags are automatically created whenever you use the DESCRIBE OBJECT command: tags are created that point to the object referenced by this command and to the defining occurrence -- the declaration -- of that object. For instance, if you used the DESCRIBE OBJECT command to inspect the values of the function 3TODAY* and the variable 3N*, DISPLAY TAG would offer the following choices: 3 today Defining occurrence of today n Defining occurrence of n* These tags point to the places in your program where 3TODAY* and 3N* were described, and to the definitions of these objects. Pointers for up to three objects are maintained by this command; if you use the DESCRIBE OBJECT command more than three times, pointers for the objects described by the three most recent uses of that command will be available. - 2Program and variable monitors.* The remaining tags in the menu point to the statements associated with any program and variable monitors you may have set. For example: 3 pm_tb_01 vm_bi_01 count* 2Problems:* If the tag you have selected is pointing into an interpreter environment file to which you do not have access, the message 3The tag 1x** is in an unviewable file and cannot be displayed will be written to the Debugger Messages pane. 2To undo:* Undoing the DISPLAY TAG command means that you want to reposition the Program Pane to that part of the file displayed before this command had been entered. This will require some number of NEXT PAGE or PREVIOUS PAGE commands to move through the file until the desired part of the file is visible. It might even be necessary to use the CHOOSE FILE command to move to a different file. If you were looking at or near one of the ends of the file, it might be easier to move to that end of the file with the FIRST PAGE or LAST PAGE command, and then move about as necessary with the PREVIOUS PAGE or NEXT PAGE commands. The FIND STRING command might also be useful.  subsection id-section6-5-3 76.5.3. DEBUGGER STATE* 2Function:* To determine the state of the debugger; in particular, to display information on the procedures, functions, and data structures on which monitors have been set. 2Result:* A message that identifies the version number of the installed Debugger and states why you have entered the debugger will be written to the Debugger Messages pane. These include: 3 - Debugger entered due to program startup - Debugger entered due to program completion - Debugger entered due to program interruption; your program is continuable. - Debugger entered due to value monitor break; your program is continuable. - Debugger entered due to program monitor break; your program is continuable. - Debugger entered due to step completion; your program is continuable. * Below this will be the tag names of each of the currently monitored statements and data structures. Monitors set on statements will appear first, followed by monitors set on data structures. 2To undo:* There is no need to undo this command, since it does not affect the internal state of the debugger or your program -- all it does is print.  subsection id-section6-5-4 76.5.4. EXECUTE* 2Function:* Transfers control to the Execute subsystem. 2Result:* The Executor will let you run your Ada program immediately -- without requiring you to click on BEGIN PROGRAM to initiate execution. The main reason for moving from the Debugger to the Executor is to take advantage of the slightly different window configuration, in which the pane containing the program listing and input/output is somewhat larger than in the Debugger. Ada programs also execute slightly faster in the Executor than they do in the Debugger. 2To undo:* To get back to the Debugger window configuration from the Executor window, you can click on DEBUG.  subsection id-section6-5-5 76.5.5. TRANSLATE* 2Function:* Transfers control to the Translation subsystem. 2Result:* You will be returned to the Translator, where you can specify a new set of files to be processed by the translator. 2To undo:* To get back to the Debugger window configuration from the Translator window, you can click on DEBUG.  subsection id-section6-5-6 76.5.6. QUIT SESSION* 2Function:* To cause the processor to cease executing CTADA and return to executing some other process. 2Result:* The CTADA window is buried and the window of the previously-selected process is exposed instead. 2To undo:* You can undo this command by typing SELECT key, where key is the letter the CTADA process was bound to when it was built (this is usually the letter "A").  chapter id-chapter-7 57. Debugging a Sample Program* The following scenario is intended to give you a few hints on how to use the Interpreter/Debugger to execute and debug an Ada program.  section id-section7-1 67.1. Create a Program* First, enter the following program into a file named ENUM.ADA: 3 with TEXT_IO; use TEXT_IO; procedure NEXT_DAY is type DAYS is (SUN, MON, TUE, WED, THU, FRI, SAT); D: DAYS; package ENUM_IO is new ENUMERATION_IO(DAYS); use ENUM_IO; function TOMORROW (DAY: in DAYS) return DAYS is begin return DAYS'SUCC(DAY); end TOMORROW; begin for DAY in DAYS loop D := TOMORROW(DAY); PUT("The day after "); PUT(DAY); PUT(" is "); PUT(D); NEW_LINE; end loop; end NEXT_DAY;* Invoke the Interpreter/Debugger by typing 3(CTADA)* to a Lisp Listener. Enter ENUM.ADA as the source file to be analyzed, omit the other three categories of files, and select 3DEBUG* as the execution mode. The translator will then begin to analyze the program, writing its analysis into the large Translator pane, as shown in Figure 7-1. This program contains no syntax or semantic errors, although there is a logical error that is included for the purposes of this example and that will be discussed later. When the translator's analysis is complete, the messages: 3 A total of 0 syntax errors and 0 static semantic errors were detected Time elapsed = 1number* seconds -- -- -- -- -- -- -- -- -- -- -- --* will be written after the translator's output. If any errors are present, check the program as you entered it against the code above, correct the errors, and repeat this step to re-run the translator. Figure 7-1: The Translator's analysis of ENUM.ADA. If no errors were detected during the analysis of the program, the Interpreter/Debugger will switch to the Debugger window configuration, as shown in Figure 7-2. Note that the translator output shown in Figure 7-1 has been moved to the bottom Ada Input/Output pane in the debugger configuration. To verify this, use the PREVIOUS PAGE command to page backwards through that window.  section id-section7-2 Figure 7-2: The Debugger's window configuration at the beginning of the debugging session. 67.2. Set Some Monitors* Next, set some monitors on the program. Use the FIND STRING command in the Program Pane to find the string 3TOMORROW*. This will position the cursor over TOMORROW's function declaration. Use the MONITOR PROGRAM command to set a program monitor on the elaboration of this declaration. The message 3 Setting a program monitor on a subprogram declaration.* will appear in the Debugger Messages pane. Select 3before* and 3trace* from the single choice menus that follow, and name the monitor 3tom*. In the Debugger Messages pane, you will see the message 3 Program monitor tom of type trace before has been set.* Next, use the mouse to point at the declaration of the variable 3D*, in line 7 of the program. Set the pane's cursor so that it is on top of the 3D*. Then, use the MONITOR VALUE command to monitor 3D*'s value. You will see the message 3 Setting a value monitor on d.* in the Debugger Messages pane. Tell the system to 3break* at 3creation* and again 3after a write*. Name the monitors 3dc* and 3da* respectively. This activity should produce the following messages: 3 Value monitor dc of type break creation has been set. Value monitor da of type break after has been set.* Note that if you try to do a DESCRIBE OBJECT on 3D* at this point, the debugger will report that 3 d is a variable with value *OUT OF SCOPE** since you have not yet started the program.  section id-section7-3 67.3. Run the Program* Start the program using the BEGIN PROGRAM command. The message 3Program execution has begun* will acknowledge this fact. The bottom window will scroll upwards, and the message 3Program execution is beginning* will appear. When the interpreter reaches the statement 3D: DAYS;*, execution will stop. The cursor will be positioned on that statement, and you will receive the following messages: 3 * Continue the program after this break point with the CONTINUE PROGRAM command. When the next break point occurs, you will have received the following series of messages: 3 Program execution has continued. d is a variable with value mon * Since 3tom* was set as a trace monitor rather than a break monitor, execution was not halted when it was encountered. However, the break monitor set on 3D* did trigger a break. Again, select CONTINUE PROGRAM to resume execution. The program will now generate output, in the form of the message 3 The day after SUN is MON* The program will hit another break point after the value of 3d* is altered again. This confirms that the 2for* loop is working correctly.  section id-section7-4 67.4. Try the Activation Record Commands* Experiment with some of the other debugger commands. Do a SHOW ACTIVATION RECORD and select the option 3all* to show all activations. In this case, there is only one activation (in addition to the outermost Ada environment, represented by the symbol 3****). This command will respond with: 3 B 0 *** is an Ada program T --> 1 next_day is a procedure* This shows that the break has taken place in the procedure 3NEXT_DAY*, which is called within the outermost Ada environment. Now, try the SHOW ACTIVATION RECORD command again, this time selecting 3current* as the option. You will receive more specific information about the current activation record: 3 T --> 1 next_day is a procedure with local variables day = mon d = tue* Use the DISPLAY TAG command to display a tagged portion of the program. When a single choice menu appears with the prompt 3Which tag?*, select the tag 3tom*. The cursor in the Program Pane will move to the function declaration of TOMORROW.  section id-section7-5 67.5. Other Commands* While in a break, use the DESCRIBE OBJECT command to inspect the values of variables in the Program Pane. For example, issuing DESCRIBE OBJECT commands with the cursor positioned on 3DAY* and 3D* will produce the messages similar to: 3 day is an iteration variable with value mon d is a variable with value tue* The exact values displayed for these variables will of course depend upon the number of times that the loop has been executed -- if you step through a few more iterations, 3DAY* might be 3FRI*, with 3D*'s value being 3SAT*. Check on the current status of the debugger using the DEBUGGER STATE command. You will receive the following reply: 3 C*T Ada Debugger release 1.7 The debugger was entered due to a value monitor break. Your Ada program is continuable. Program monitors. tom Value monitors. da dc*  section id-section7-6 67.6. Is There a Bug?* Since the 2for* loop appears to be working, change the monitor on the variable 3d* to a trace so that execution will not be interrupted each time through the loop. Use the REMOVE MONITOR command to remove monitor 3da*, then use MONITOR VALUE to set a 2trace after* monitor called 3dta*. Continue the program once again using CONTINUE PROGRAM. As the program runs, you will receive a series of trace messages in the middle window, as follows: 3 d is a variable with value wed d is a variable with value thu d is a variable with value fri d is a variable with value sat * The program will then terminate, but with a constraint error. The Ada Input/Output pane will contain: 3 Begin Ada Execution The day after SUN is MON The day after MON is TUE The day after TUE is WED The day after WED is THU The day after THU is FRI The day after FRI is SAT There was no exception handler for constraint_error. Program execution has ended. Time Elapsed = 1number* seconds.*  section id-section7-7 67.7. Fix the Bug* To correct this error, you will need to leave the Interpreter/Debugger. This error is caused by a flaw in the TOMORROW function. Use a text editor to change its definition to: 3 function TOMORROW (DAY: in DAYS) return DAYS is begin if DAY=SAT then return SUN; else return DAYS'SUCC(DAY); end if; end TOMORROW;* Rerun the corrected program through the Interpreter/Debugger. This time, when the program completes execution, the Ada Input/Output pane should contain the correct program output: 3 Begin Ada Execution The day after SUN is MON The day after MON is TUE The day after TUE is WED The day after WED is THU The day after THU is FRI The day after FRI is SAT The day after SAT is SUN End Ada Execution*  chapter id-appendix-f 5F. Implementation-Dependent Characteristics* This appendix describes the implementation-dependent characteristics of the Computer * Thought Ada Interpreter. - 2Implementation-dependent pragmas:* There are no implementation-dependent pragmas. - 2Implementation-dependent attributes:* There are no implementation-dependent attributes. - 2Package SYSTEM*: 3 package SYSTEM is type ADDRESS is new INTEGER; type NAME is (CTADA3600); SYSTEM_NAME : constant NAME := CTADA3600; STORAGE_UNIT : constant := 32; MEMORY_SIZE : constant := 2**32; -- system-dependent named numbers MIN_INT : constant := -2**32; MAX_INT : constant := (2**32)-1; MAX_DIGITS : constant := 9; MAX_MANTISSA : constant := 0; FINE_DELTA : constant := 0; TICK : constant := 0.0166667; -- other system-dependent declarations subtype PRIORITY is INTEGER range 1..1; end SYSTEM;* - 2Restrictions on representation clauses:* Representation clauses are not supported. - 2Conventions for implementation-generated names:* There are no implementation-generated names. - 2Interpretation of expressions in address clauses:* Address expressions are interpreted as 30-bit addresses of the first word of the object. - 2Restrictions on unchecked conversions:* Unchecked conversions are not supported. - 2Implementation-dependent characteristics of the input-output packages:* * If any external files are left open after the termination of the main program, they will automatically be closed. * Input/output for access types is not supported. * Temporary files are created in the user's login directory, and will be deleted upon the termination of the main program. * The following type declarations are present: - In the DIRECT_IO package: 3 type COUNT is range 0 .. 1000;* - In TEXT_IO: 3 type COUNT is range 0 .. 132; subtype FIELD is INTEGER range 0 .. 10;* * The FORM parameter in file specifications is not supported; use an empty string (3""*) when a FORM parameter must be specified. * The names given to external files must obey the restrictions of the file server on which they reside. The effect of overwriting an existing file (i.e., the assignment of a unique version number to the new version of the file, or the renaming or erasure of the old version of the file) is determined by the interaction of the machine on which the Interpreter/Debugger resides and the file server on which the file is being written. See the host system documentation for more information. * The number of files allowed open simultaneously depends upon the characteristics of the file server(s) on which the file(s) exist. A NAME_ERROR will be raised when the number of created and opened files exceeds the limit of a host. * The optional pre-defined types SHORT_INTEGER, LONG_INTEGER, and LONG_FLOAT are not defined. * The package LOW_LEVEL_IO is not defined. - 2Implementation-dependent characteristics of MAIN PROGRAM* specification: The interpreter will treat as the 2main program* (i.e., the procedure that will be called to begin execution of the user's program) the first parameter-less procedure that is also a compilation unit. If no procedure is encountered that meets these criteria, a PROGRAM_ERROR will be raised.