Explicit line numbers and execution order

Question

GW-BASIC and many other old BASIC dialects like C64 BASIC allowed you do something like this:

20 PRINT "World"
10 PRINT "Hello"

and that would result in the following output when the RUN command/statement was executed:

Hello
World

The LIST command/statement would list the program:

10 PRINT "Hello"
20 PRINT "World"

In other words, those BASIC dialects would automatically re-order the execution to fit the order specified by the line numbers you used, regardless of the order in which you originally typed/saved them in another editor (e.g. EDLIN.EXE). However, QuickBASIC and BASCOM2 failed to do the same.

The oldest QuickBASIC version I could find online was QuickBASIC 2.0, and it didn't work there, simply ignoring the line numbers to print things in the order I wrote them (i.e. "World Hello").

BASCOM2—the oldest MS/IBM BASIC compiler I could find—also apparently didn't support the feature, instead failing with an error (SQ = Out of order sequence?):

 0046   0006    10 PRINT "Hello"
                ^ SQ

50434 Bytes Available
50325 Bytes Free

    0 Warning Error(s)
    1 Severe  Error(s)

While I certainly understand how often line numbers are superfluous, it seemed like a useful feature to support execution in explicit line number order (20, 10, 30 => 10, 20, 30) rather than implicit line number order (20, 10, 30 => 20, 10, 30).

Does anybody have any idea why this traditional BASIC behavior was ignored?

Older dialects (GW-BASIC) probably placed the code into an array indexed by the line number. — eoredson, Jul 09 '18 at 04:17
The line number in the GW-BASIC programs IS the order in which the instructions shall be EXECUTED. — Sir Jo Black, Dec 12 '18 at 16:38

score 3 · Accepted Answer · answered Feb 03 '18 at 01:52

I'm surprised that the first bascom you found reported an error. All compilers that I've ever used for BASIC, and I believe I've used a lot of them since 1982 on, made line numbers optional and supported labels. I remember that in my first job as a professional programmer, we designed a compiler pre-processor that would insert only lines needed for proper IF, ELSE IF and END IF statements by replacing stuff with line numbers and (gasp) GOTO statements.

I still use line numbers today in my still supported VB6 accounting application thanks to MZ-Tools add-in that allows me to add and remove line numbers to my methods and function with a single button click. This allows me to use Erl (error line number) in all my error routines, also a quick one-button add to all my methods and functions, which allows me to pin-point the exact line any error occurs on.

I'm sure the compiler designers thought that line numbers were only of real use to interpreters, and perhaps the first version of bascom figured you'd develop and test with an interpreter, then compile and distribute the executable, then perhaps later versions figured developers were using text editors, especially the later versions that came with their own IDE's and who would need line numbers there? Well, we do if we want precise error reporting! That's one thing I like about Java and Eclipse. The line numbers are there so I can know exactly where the errors are, but they don't get in the way like they do in BASIC (remove line numbers, add/remove code, replace line numbers).

Lately, I've come to the conclusion that they simply became impractical and outdated. "Traditional" BASIC interpreters were command-based and allowed you to edit line 20 by typing `EDIT 20` for example (or just entering `20 {new code here}`), but the advent of visual editors like DOS EDIT and Unix vi meant this feature was unnecessary. Explicit line numbers were similarly deemed less necessary as the given order of lines could be used instead. This freed precious RAM for other purposes as an array (and its search/insertion algorithm) was no longer required for keeping execution ordered. — , Dec 16 '18 at 05:06

score 1 · Answer 2 · edited Oct 23 '22 at 00:39

IBMs handbook for the compiler says in appendix A („Messages from the Compiler“):

SQ Sequence error

The line numbers in your program were not in sequence, or contained a duplicate statement number.

The BASCOM compiler doesn't need line numbers on every line if the /N option is given:

If you use a text editor other than the BASIC program editor, you can create a file of lines without line numbers. The compiler supports sequences of lines without line numbers if the /N parameter is specified when you start the compiler. This feature can make it very easy to include the same file in many different programs.

In case of BASCOM most probably memory and runtime was the reason to not read in the complete file into memory at once and sorting the lines according to line numbers. The compiler analyses the file line by line while reading them and is able to fail fast for many errors that need just the knowledge of a single line plus the information gathered from previously seen lines. This was an important point back then when it was common to run all of this from slow floppy disk drives.

The interpreter on the other hand treated BASIC programs read from text files simply as if the user manually entered them line by line. So the line number was used to determine the relative position to the other lines in the program.

Later dialects like QBasic treated line numbers just as labels. The following behaves like the well known classic in QBasic, but prints just one line in earlier dialects:

20 PRINT "Hello, World!"
10 GOTO 20

If each line has a line number it might be reasonable to expect them to be reordered before execution, although it might get confusing to the programmer that the order of the lines they edit, isn't the order the lines are executed when there are no statements that imply jumps.

Now imagine not all lines are numbered and the program is larger than just a two line toy example. Take this (incorrect) code for example:

    GOSUB 100
    FOR i = 1 TO 10: GOSUB 200: NEXT
    END
                                                                              
200 PRINT "frobnicate"
    RETURN

    DATA 1,2,3

100 PRINT "Do some special preparation and"
    PRINT "then fall through to frobnicate"
    REM ...
    
    DATA 4,5,6

What would reordering mean? It must be at least meaning to move all the lines following the line number up to the next line number (or label). What about DATA lines? Move them too or leave them in the same order? It may very quickly become a mess for the human reader to understand the actual program flow in such a program.

Even with the interpreter, where having numbered lines out of order in a text source file is okay for the interpreter, I guess human readers will be confused easily and the programmer would use the sort lines function of the text editor of choice or an external sorting program. It's also easier to spot accidentally replacing earlier entered lines with the same line number then.

So there's not really a compelling use case for interpreters and compilers that don't need line numbers to reorder lines with line numbers (+ the following ones without) and working with „out of sequence“ lines is already confusing with interpreters that do require line numbers.

Explicit line numbers and execution order

2 Answers2