The ON-GOTO tests are all readily understandable. The one thing you might want to watch for is that the processor rounds the expression controlling the ON-GOTO to the nearest integer, as specified in the standard. Thus, "ON .6 GOTO", "ON 1 GOTO", and "ON 1.4 GOTO" should all have the same effect; there should be no out of range exception for values between .5 and 1.

5.10 READ, DATA, And RESTORE

This group tests the facilities for establishing a stream of data in the program and accessing it sequentially. This feature has some subtle requirements, and it would be wise to read the standard especially carefully so that you understand the purpose of the tests.

5.10.1 Standard Capabilities

All but the last of these tests are reasonably simple. The last test dealing with the general properties of READ and DATA, although self-checking, has somewhat complex internal logic. It assures that the range of operands of READ and DATA can overlap freely and that a given datum can be read as numeric at one time and as a string at a later time. If you need to examine the internal logic closely, be sure to use the REM statements at the beginning which break down the structure of the READ and DATA

The exceptions can be understood directly from the programs. Note that string overflow may or may not occur, depending on the implementation-defined maximum string length. If overflow (loss

of

data) does occur, the processor must report an exception and execution must terminate. If there is no exception report, look carefully at the output to assure that no loss of data has occurred.

5.10.3 Errors

All of the error tests display results if the implementation accepts them, allowing you to check that the documentation matches the actual behavior of the processor. Some of the candidates for enhancements and

illegal
thus the diagnostic feature is important here.

constructs are likely

5.11 INPUT

This group, like that for PRINT, calls for a good deal of user participation. This participation takes the form, not only of interpreting program output but also of supplying appropriate INPUT replies. The validity of this group depends strongly on the entry of correct replies.

5.11.1 Standard Capabilities

accept as absolutely

The first program assures that the processor can input any syntactically valid number. It is essential, then, that you reply to each message with precisely the same set of characters that it asks for. If it tells you to enter "1.E22" you must not reply with, e.g. "1E22". This would defeat one of the purposes of that reply, which is to see whether the processor correctly handles a decimal point immediately before the exponent. Once you have correctly entered the reply, one of several things can happen. If the processor in some way rejects the reply, for instance by producing a message that it is not a valid number, then the processor has failed the test since all the replies are in fact valid according to the standard. To get by this problem, simply enter any number not numerically equal to the one originally requested. This will let you get on to the other items, and will signal a failure to the processor as described below.

If the processor accepts the reply, the program then tests that six digits of accuracy have been preserved. If so, you will get a message that the test is OK, and may go on to the next reply. If not, you will get a message indicating that the correct value was not received, and the program will ask if you want to retry that item. If you simply mistyped the original input-reply, you should enter the code for a retry. If your original reply was correct, but the processor misinterpreted the numeric value, there is no point to retrying; just go ahead to the next item. The program will count up all the failures and report the total at the end of the program.

The next program, for array input, assures that you can enter numbers into an array, and that assignments are done left to right, so that a statement such as "INPUT I, A(I)" allows you to control which element of the array gets the value. Also, it is here (and only here) that the standard's requirement for checking the input-reply before assignment is tested. Your first reply to this section of the test must cause an exception, and you must be allowed to re-enter the entire reply, otherwise the test fails. The rest of the program is self-checking.

The program for string input comes next and, as with the numeric input program two considerations are paramount: 1) you should enter your replies exactly as indicated in the message and 2) all input replies are syntactically valid and therefore if the

implementation rejects

A

any of them, it fails the test. potentially troublesome aspect of this program is that the prompting message cannot always look exactly like your reply. In particular, your replies will sometimes include blanks and quotes. It is impossible to PRINT the quote character in Minimal BASIC, SO the number-sign (#) is used instead. For ease of counting characters, an equals (=) is used in the message to represent blanks. Therefore, when you see the number-sign, type the quote and when you see the equals, type the blank. If you forget, the item will fail and you will have a chance to retry, so make sure that a reported failure really is a processor failure and not just your own mistyping before bypassing the retry. As with the numeric input, if the processor rejects of the replies, simply enter any reply whose evaluation is not equal to that of the prompting message to bypass the item and force a failure. The second section of the string input program does not use the substitute characters in the message;

one

rather

you always type exactly what you see in the message surrounded by quotes.

the

conventions

The program for mixed input follows individually established by the numeric and string input programs. Its purpose is simply to that the implementation can handle both string and numeric data in the same reply.

assure

Unlike the other groups, where each exception type is tested with its own program, all the mandatory exceptions for INPUT are gathered into one routine. There are two reasons for this: first, there are so many variations worth trying that a separate program for each would be impractical, and second, the recovery procedures are the same for all input exception types. It is, then, both economical and convenient to group together all the various possibilities into one program. Underflow on INPUT is an optional exception and has a different recovery procedure, governed by the the semantics for numeric constants rather than INPUT. It, therefore, is tested in its own separate program.

test.

The

The conformance requirements for input exceptions are perhaps the most most complex of any in the standard. It is worthwhile to review these requirements in some detail, and then relate them to the standard says that "unquoted-strings that are numeric-constants must be supplied as input for numeric-variables, and either quoted-strings or unquoted-strings must be supplied as input for string-variables." Since the syntactic entities mentioned are well-defined in the standard, this specification seems clear enough. Recall,

however, that processors can, in general, enlarge the class of syntactic objects which they accept. In particular, a processor enhanced definition of quoted-string, generally,

may

an

have unquoted-string, numeric-constant,

or,

more

may

on

input-reply, and therefore accept a reply not strictly allowed by the standard, just as standard implementations may accept, and render meaningful, non-standard programs. The result is that the conditions for an input exception depend implementation-defined features, and thus a given input-reply may cause an exception for one processor and yet not another. Note that the same situation prevails for overflow the exception depends on the implementation-defined maximum string length and machine infinity. Thus, "LET A = 1E37 * 100" may cause overflow on one standard processor, but not another.

not

When running the program then, a given input-reply need generate an exception if there is a documented enhancement which describes its interpretation. Of course, such an enhancement must not change the meaning of any input-reply which is syntactically standard. Note that, of the replies called for the program, some are syntactically standard and some are not; they should, however, all cause exceptions on a truly minimal BASIC processor, i.e. one with no syntactic enhancements, with machine infinity = 1E38 and with maximum string length of 18.

a

in

as

Another problem is that, for some replies, it is not clear which exception type applies. If, for instance, you respond to "INPUT A,B,C" with: "2,,3", it may be taken as a wrong type, since numeric-constant was not supplied for B, or insufficient data, since only two, not three, were supplied. In such a case, as with all exception as with all exception reports, it is sufficient if the report is a reasonably accurate description of what went wrong, regardless of precisely how the report corresponds to the types defined in the standard.

As with all non-fatal exceptions, it is permitted for an implementation to treat a given INPUT exception as fatal, if the hardware or operating environment makes the recovery procedure impossible to follow. The program is set up with table-driven logic, so that each exception is triggered by a set of values in a given DATA statement. If you need to separate out some of the cases because they cause the program to terminate, simply delete the DATA statements for those cases. REM statements in the program describe the format of the data.

After that lengthy preliminary discussion, we now ready to consider how to operate and interpret the test. The program will ask you for a reply, and also show you the INPUT statement to which it is directed, to help you understand why the exception should occur. Enter the exception-provoking reply, exactly as requested by the message. If all goes well, the implementation will give you an exception report and allow you to re-supply the entire input-reply. On this second try, simply enter all zeros, exactly as many as needed by the complete original INPUT statement, to bypass that case this will signal the program that that case has passed, and you will then receive the next message.

wrong.

If

Now, let us look at what might go the implementation simply accepts the initial input-reply, the program will display the resulting values assigned to the variables and signal a possible failure. If the documentation for the processor describes an enhancement which agrees with the actual result, then that case passes; otherwise it is a failure.

Suppose the implementation reports an exception, but does

not allow you to re-supply the entire input-reply. At that

point, just do whatever the processor requires to bypass that You should supply non-zero input to signal the program that the case in question has failed.

case.

When the program detects an apparent failure (non-zeros in the variables) it allows you to retry the whole case. As before, if you mistyped you should reply that you wish to retry; if the processor simply mishandled the exception, reject the retry and move on to the next case.

Figure 3 outlines the user's operating and procedure for the INPUT exception test.

interpretation

5.11.3 Errors

There is only one error program and it tests the effect of a null entry in the input-list. The usual rules for error tests apply (see section 4.4.2.3).