Reading Measurements with Single Units

An earlier version of a measurement program accepted one measurement at a time. A user could type '3 miles' or '1ft', and the program would convert that single measurement into inches, feet, yards, and miles. This design works well until a user types what people naturally say, such as '3 feet 7 inches'.

A single line can now hold several measurements, and each one has its own number and its own unit. The program has to read every one of them from the same line and combine them into one total. This article follows the subroutine that does that job and explains the reasoning behind its structure.

Set aside illegal inputs for the moment, and the core idea is a running total. The subroutine starts with zero inches. It then repeats one three-part step for each measurement on the line: read the number, read its unit, and add the matching amount to the total. When no measurements remain, it returns the total.

The subroutine recognizes four legal units of measure: inch, foot, yard, and mile. A user may write any of them in singular form, plural form, or abbreviation. Plural spellings such as 'feet' do not follow the simple pattern of adding an s to the singular, so the program must recognize them as their own forms. Lines such as '1 foot' and '3 miles 20 yards 2 feet' are valid because every token after a number is one of the recognized unit forms.

The draft leaves one question open: how does the program decide that more input remains? A natural approach is to look at the next character and ask whether it is the end-of-line character. The source notes that TextIO.peek() does exactly this kind of look. It examines the next character without consuming it, so the test does not remove anything from the input.

Because the peek leaves the character in place, the reading code that runs next still sees the same number. The peek is a look, not a read. This is why the loop test can be placed before any reading happens without losing a measurement.

A peek alone is not enough. If the next character is a space, the end-of-line test tells you nothing useful about whether a measurement follows. The character being examined must be either the end-of-line or a non-blank character that starts a measurement. A space is neither, so it must be dealt with first.

The fix is a skipBlanks step. Skipping blanks guarantees that the next character is either the end-of-line or the start of a measurement, which makes the end-of-line test meaningful. The improved algorithm calls skipBlanks once before the loop, and again at the end of each pass. The first peek must already see a meaningful character, which is why the call before the loop matters.

The same logic can be read as a sequence of decisions. Each time the program reaches the test, it either takes the loop path to process another measurement or leaves the loop to return the total. The loop is the only place where control can leave the repetition, and the exit happens only when the test finds the end of the line.

Notice that the exit check runs at the top of every pass, not just once. The loop does not count how many measurements it expects. It keeps going while the test finds a measurement, and it stops only when the end of the line appears.

The algorithm so far ignores illegal inputs on purpose. A robust version still needs a plan for them, because a line can contain a misspelled unit, a missing number, or other problems. The source states that if there is any error in the line, the subroutine prints an error message and returns the value -1. This rule is an addition on top of the base logic.

The main program uses a separate convention for ending the session: an empty line. It tests for this before calling the subroutine, because the subroutine assumes the line it receives is not empty. Keeping these two responsibilities apart means the subroutine focuses on converting one line, while the main program controls the flow of the whole session.