« 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.
The first program assures that the processor can accept
as input any
syntactically valid number. It is absolutely 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.8. "1 E 22". 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,
of several things can happen. If the processor in some way rejects the reply, for instance by producing a message that it is
a not a valid number, then the processor has failed the test since all
the replies are in fact valid according to the standard. Το 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
a head 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
the entire reply, otherwise the test fails. The rest of the program is self-checking.
and, The program for string input comes next
with the numeric
1) you input program two considerations are paramount: should enter your replies exactly as indicated in the message and 2) all input replies are syntactically valid and therefore if the
implementation rejects any
test. A potentially troublesome aspect of this program
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 (#)
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 reported failure really
a processor failure 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; rather you always type exactly what you see in the message surrounded by quotes.
The program for mixed input follows the conventions individually established by the numeric and string input programs. Its purpose
is simply to assure that 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.
is worthwhile to review these requirements in some detail, and then relate them to the test. The standard says that "un quoted-strings that are numeric-constants must be supplied as input for numeric-variables, and either quoted-strings or un quoted-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 may have an enhanced definition of quoted-string, 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.
programs. The result is that the conditions for an input exception may depend on 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 = 1837 * 100" may cause overflow
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
a truly minimal BASIC processor,
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 wrong type, since numeric-constant was not supplied for B,
or as insufficient data, since only two, not three, were supplied. In such a case, 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
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
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.
Now, let us look at what might go
wrong. If 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 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 move on to the next case.
Figure 3 outlines the user's operating procedure for the INPUT exception test.
There is only one error program and it tests the effect of a null entry
the input-list. The usual rules for error tests apply (see section 188.8.131.52).
Instructions for the INPUT exceptions test
Inspect message from program
if processor allows you to re-supply entire reply
zeros not assigned to variables
test failed (recovery procedure not followed) endif 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 then
test passed else (no exception and incorrect/missing documentation)
test failed endif endi