« PreviousContinue »
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 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
any of them, it
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 and not just your own mistyping before bypassing the retry. As with the numeric input, if the processor rejects one 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; you always type exactly what you see in the message surrounded by quotes.
The program for mixed input individually established by the numeric is simply to
and string input
programs. Its purpose the implementation can handle both string and numeric data in the same reply.
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 semantics for numeric constants rather than INPUT. It, therefore, is tested in its own separate program.
The conformance requirements for input exceptions are perhaps the most complex of any in the standard. It is worthwhile to review these requirements in some detail, and then relate them to the test. 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,
have unquoted-string, numeric-constant,
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 may 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.
When running the program then, a given input-reply need not 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 in 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.
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 as insufficient data, since only two, not three, were supplied. In such 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
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 are 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 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 message.
receive the next
the input-reply, the
Now, let us look at what might go implementation simply accepts the initial 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 case. You should supply non-zero input to signal the program that the case in question has failed.
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 on to the next case.
Figure 3 outlines the user's operating and procedure for the INPUT exception test.
There is only one error program and it tests the effect of a null entry in the input-list. The usual rules for apply (see section 126.96.36.199).
Instructions for the INPUT exceptions test
Inspect message from program
Supply exact copy of message as input-reply
If processor reports exception
if processor allows you to re-supply entire reply
enter all zeros (exactly enough to satisfy original
if processor responds that test passed
else (no pass message after entering zeros)
test failed (recovery procedure not followed)
else (not allowed to re-supply entire reply)
supply any non-zero reply to bypass this case test failed (recovery procedure not followed) endif
else (no exception report)
if documentation for processor correctly describes syntactic enhancement to accept the reply
else (no exception and incorrect/missing documentation)