Page images
[blocks in formation]

Numeric expressions have a somewhat special place in the Minimal BASIC standard. They

are the most complex entity, syntactically, for two reasons. First, the expression itself may be built up in a variety of ways. Numeric constants, variables, and function references are combined using any of

five operations. The function references themselves may be to user-defined expressions. And

of course expressions can

be nested, either implicitly, or explicitly with parentheses. Second, not only do the expressions have a complex internal syntax, but also they may appear in a number of quite different contexts. Not just the LET statement, but also the IF, ON... GOTO,

and FOR statements, can contain expressions. Also they may be used as array

subscripts or as arguments in function reference. Note that when they are used in the ON... GOTO, as subscripts, or as arguments to

expressions must be rounded to the nearest integer.




The overall strategy of the test system is first to assure that the elements of numeric expressions are handled correctly, then to


out increasingly complex expressions in the comparatively simple context of the LET statement, and finally to verify that these complex expressions work properly in the other contexts mentioned. Preceding groups have already accomplished the first task of checking out individual expression elements, such

constants, variables (both simple and array), and function references. This group completes the latter two steps.



Standard Capabilities In Context of LET-statement

This test tries out various lengthy expressions, using the full generality allowed by the standard, and assigns the resulting value to a variable. As usual, if this value is even approximately correct, the test passes, since we are interested in semantics rather than accuracy.

The program displays the correct value and actual computed value. This test also verifies that subscript expressions evaluate to the nearest integer.


Expressions In Other contexts: PRINT, IF, ON-GOTO, FOR


Please note that the PRINT test, like other PRINT tests, is inherently incapable of checking itself, and therefore you must inspect and interpret the results. The PRINT program first tests the use of expressions as print-items. Check that the actual and correct values are reasonably close. The second section of the program tests that the TAB call is handled correctly. Simply verify that the characters appear in the appropriate columns.

IF ,

The second program is self-checking and tests

ON-GOTO and FOR, one


each section. As with other tests of control statements, the diagnostics

rather sparse for failures. Check Volume 2 for an example of correct output.



Exceptions In Subscripts And Arguments

The exceptions specified in section 7 and 8 apply to numeric expressions in whatever context they occur. These tests simply assure that the correct values are

supplied, e.g.,

machine infinity for overflow, zero for underflow, and that the execution continues normally as if that value had been put in that context as,

say, a numeric constant. Sometimes this action will produce normal results and sometimes will trigger another exception, e.g.,

machine infinity supplied as a subscript. Simply verify that the exception reports are produced as specified in the individual tests.


Exceptions In Other Contexts: PRINT, IF, ON-GOTO, FOR

As in the immediately preceding section, these tests make sure that the recovery procedures have the natural effect given the context in which they occur. As usual for exception tests, it is


to verify that reasonable exception reports appear. The PRINT tests also require user interpretation to degree.


5.15 Miscellaneous Checks

This group consists mostly of error tests in which the error is tied not to some specific functional area but rather to the general format rules for BASIC programs. If you are not already thoroughly familiar with the general criteria for error tests, it would be wise to review them (sections 3.2.2 and of this document) before going through this group. A few tests require special comment and this is supplied below in


appropriate subsection.

[blocks in formation]

Many implementations of BASIC allow programs to omit

the keyword LET in assignment statements. This program checks that possibility and reports the resulting behavior if accepted.

[blocks in formation]
[ocr errors]

Sections 3 and 4 of the ANSI standard specify several context sensitive rules for the occurrence of spaces in a

a BASIC program. The standard test assures that wherever one space may occur,

several spaces may occur with no effect, except within a quoted- or unquoted-string. There are certain places where spaces either


or may not appear, and the error programs test how the implementation treats various violations of the rules.


[blocks in formation]



These programs test the effect of using either single double quote in a quoted string.

string. Some processors may interpret the double quote as a single occurrence of the quote character within the string. The

programs test the effect of aberrant quotes in the context of the PRINT and the LET statements.

[blocks in formation]


The first of these programs is a a standard, not

error, test. It verifies that leading zeros in line numbers have no effect. The other programs all deal with some violation of the syntax rules for line numbers. When submitting these programs to your implementation, you should not explicitly call for any sorting or renumbering of lines. If the implementation sorts the lines by default, even when the program is submitted to it in the simplest way, the documentation must make this clear. Such sorting merely constitutes particular type of syntactic enhancement, i.e., to treat a program with lines out of order as if they were in order. Similarly, an implementation may discard duplicate lines, or append line numbers to the beginning of lines missing them, as long as these actions occur without special user intervention and are documented. Of course, processors may also reject such programs, with an error message to the user.


[blocks in formation]

This program tests the implementation's reaction to a line whose length is greater

than the standard limit of 72. Many implementations accept longer lines; if SO the documentation must specify the limit.

[blocks in formation]
[ocr errors]

This is not an

an error

error test, but a standard one. Further, it involves PRINT capabilities and therefore calls for careful user interpretation. Its purpose is to assure correct handling of the margin and print zones, relative to the implementation-defined length for each of those two entities. After

you have entered the appropriate values, the program will generate pairs of output, with either one or two printed lines fo each member of the pair. The first member is produced using primitive capabilities of PRINT and is intended to show what the output should look like. The second member of the pair is produced using the facilities under test and shows what the output actually looks like. If the two members differ at all, the test fails. It could happen, however, that the first member of the pair does not produce the correct output either. You should, therefore, closely examine the sample output for this test in Volume 2 to understand what the expected output is. Of course the sample is exactly correct only for implementations with the same margin


zone width, but allowing for the possibly different widths of your processor, the sample should give you the idea of what your processor must do.

[ocr errors]
[blocks in formation]

These two tests tell you whether your processor can handle lowercase characters in the program, and, if so, whether they are converted to uppercase or left as lowercase.

[blocks in formation]

This program tests whether

your implementation accepts comparison operators other than the standard or <> for strings. If the processor does accept them, the program assumes


that the interpretation


the intuitively appealing one and prints informative output concerning the implicit character collating sequence and also some comparison results for multi-character strings.

[blocks in formation]

These programs check whether the processor accepts assignment of a string to a numeric variable and vice-versa, and if so what the resulting value of the receiving variable is. AS usual, make sure your documentation covers these cases if the implementation accepts these programs.



This section contains three tables which should help you find your way around the programs and the ANSI standard. The first table presents the functional grouping of the tests and shows which programs are in each group and the sections of the ANSI standard whose specifications are being tested thereby. The second table lists all the programs individually by number and title, and also the particular sections and subsections of the standard to which they apply.

apply. The third table lists the sections and subsections of the standard in order, followed by a list of program numbers for those sections. This third table especially important if you want to test the implementation of only certain

parts of the standard. Be aware, however, that since the sections of the standard are not tested in order, the tests for a given section may rely on the implementation of later sections in the standard which have been tested earlier in the test sequence.


« PreviousContinue »