5 ms·

The line numbers in BASIC were arbitrary. People often started at higher numbers and jumped by 10 in case they had to put code or comments before or between lin

The line numbers in BASIC were arbitrary. People often started at higher numbers and jumped by 10 in case they had to put code or comments before or between lines.

colejohnson66 10y ago
Could line numbers be out of order? Like, if I did this: 10 PRINT "1" 30 PRINT "2" 20 GOTO 10 What would print out? Just a bunch of "1"s or "12"s?
- allenu 10y ago
  It gets run in the correct order. Think of each line as a command that stores the instruction immediately at that line number. You could actually "re-type" a line later by reusing the same line number but replacing it with new contents.
  - kqr 10y ago
    "Correct" order is ambiguous to someone asking that question in the first place.
    - colejohnson66 10y ago
      It sounds like he's saying the "line number" is just the index to a tokenized list (i.e. line 15 is at `lines[15]') where unused lines are just nops. So my "program" would be tokenized and the lines stored like: char** lines = malloc(...); lines[10] = &line1; lines[30] = &line2; lines[20] = &line3; Then when executing, it starts at `lines[0]', sees nops, gets to `lines[10]' and runs it, sees more nops, gets to `lines[20]' and jumps to `lines[10]'. All the while ignoring `lines[21]' and up.
      - abecedarius 10y ago
        Usually in 8-bit BASICs the lines would be stored consecutively (not in separate malloced segments) with each line starting with its line number. Yes, this meant that GOTO required a search. Memory was a really central design constraint on these systems. I don't know how closely MS's BASICA on the PC followed this model, but the PC's starting configuration had 16k bytes of RAM.
        david-given 10y ago
        Here's a description of the file format used by BBC Basic: http://xania.org/200711/bbc-basic-v-format http://xania.org/200711/bbc-basic-v-format That's Basic V, which was the variant used on the ARM-based Archimedes, but it's the same file format as the 6502 machine Basics. Note that the line numbers used by GOTO and GOSUB were specially flagged --- this was so the RENUMBER command could find them. It also meant that computed gotos weren't renumbered... (Of course, BBC Basic had proper named procedures and functions with local variables, but all self-respecting Basics had to support GOTO and GOSUB.)
  - webtechgal 10y ago
    Spot on - so line 30 would never get executed on that code, and a series of '1's will get printed, in an endless loop, until stopped with a Ctrl-C.
  - Etheryte 10y ago
    What is "correct order"? You forgot to answer the actual question.
    - allenu 10y ago
      Sorry, it was ambiguous. I assumed the writer of the original code intended to execute them in the order of the line numbers and that was the "correct order". Otherwise, the line numbers are meaningless.
- Iv 10y ago
  It would only print "1"s. The thing is that basic programs were not entered through a 2D text-editor per rather line per line. You would type "LIST" to re-read the whole program you typed so far, with the lines in the correct order. Then, you would enter a line starting with a number. It would overwrite any existing line with the same number. Typically, a way to correct the program you wrote would be to type: 30 15 PRINT "2" (replace the line 30 by an empty line, and insert a line number 15)
  - andyjohnson0 10y ago
    Just to add that some BASIC dialects had a RENUMBER or RENUM command that would change all line numbers and references to use a consistent interval. Without that, programs could become hard to modify due to the "gaps" between the lines closing-up.
    - DanBC 10y ago
      Which is one cause of the spaghetti: 17 GOSUB 5500
    - colejohnson66 10y ago
      Couldn't you just increment by 100? Or even 1000? Why did everyone use 10? Was it some interpreter limit that didn't allow line numbers above a certain amount (like 2^15 on a 16-bit CPU)?
      - tallanvor 10y ago
        Certainly, it would in part depend on the support of the interpreter, though. Realistically, incrementing by 10 was easy, and if you really needed more you could use goto to jump down and back (though obviously that's not nice for readability).
      - Klathmon 10y ago
        Providex (a basic dialect that my company still uses) has a soft-ish limit of around 52000 for line numbers. You can get around that with some flags, but its more of a pain than its worth. We tend to go by hundreds for programs, and we have a renumber command, but using it is the nuclear option because it will break goto line number references from outside programs (yeah, that's a very common thing in this language)
- DanBC 10y ago
  If you typed those lines, then issued a LIST command, the interpreter would return 10 PRINT "1" 20 GOTO 10 30 PRINT "2" You don't have to type LIST to reorder the lines, that just shows the re-ordering to you. If you didn't type LIST, but did type RUN (with the "unordered" listing) the interpreter would run each line in sequence of line number. If you ran out of line numbers you could sometimes RENUMber the listing. Here's Stackoverflow: This question is marked as a duplicate: http://stackoverflow.com/questions/2435488/why-basic-had-numbered-lines http://stackoverflow.com/questions/2435488/why-basic-had-num... Here's the closed question it's marked as a duplicate of: http://stackoverflow.com/questions/541421/why-did-we-bother-with-line-numbers-at-all http://stackoverflow.com/questions/541421/why-did-we-bother-...
  - deleted 10y ago
    [deleted]
- alblue 10y ago
  It would print out a series of 1s. It is the same as if you had entered 10 PRINT "1" 20 GOTO 10 30 PRINT "2" The reason this is allowed is because it let you rewrite existing programs; if you later entered 10 PRINT "Hello World" It would replace the original line 10 and use this one instead.
- bencollier49 10y ago
  Not an especially valuable comment from me here, but the fact that people who are probably very technically literate can ask this question makes me feel really rather old.
  - jhbadger 10y ago
    I remember explaining line-number based BASIC to a younger programmer once and he really couldn't get his head around the idea of GOTOs and GOSUBs based on line numbers -- "why wouldn't you just define functions?"
    - jerf 10y ago
      I remember the minor shock I experienced when writing programs without line numbers. I recall a couple of "good at programming whiz kids" never could make the transition and dropped the compsci major. I escaped the "permanent brain damage" that Dijkstra complained about that era of BASIC producing, but I understand where he's coming from now and don't begrudge him the slight hyperbole. It was a language where there were so many accidental complexities that there was virtually no prayer of someone penetrating through to the essential issues, using Fred Brook's definitions of accidental/essential. You're not learning anything useful while you're manually renumbering lines because you used up everything between 15-20 and fixing up the GOTOs. (I never had anything with RENUM support.)
webtechgal 10y ago
Well noted. I recall there also used to be a STEP command in the basic interpreter (basica and gw-basic) with which the line number increment could be set e.g. STEP 5 will auto-increment the line numbers by 5. (The default used to be 10.)

The line numbers in BASIC were arbitrary. People often started at higher numbers and jumped by 10 in case they had to put code or comments before or between lines.

colejohnson66 10y ago

Could line numbers be out of order? Like, if I did this: 10 PRINT "1" 30 PRINT "2" 20 GOTO 10 What would print out? Just a bunch of "1"s or "12"s?

allenu 10y ago
It gets run in the correct order. Think of each line as a command that stores the instruction immediately at that line number. You could actually "re-type" a line later by reusing the same line number but replacing it with new contents.
- kqr 10y ago
  "Correct" order is ambiguous to someone asking that question in the first place.
  - colejohnson66 10y ago
    It sounds like he's saying the "line number" is just the index to a tokenized list (i.e. line 15 is at `lines[15]') where unused lines are just nops. So my "program" would be tokenized and the lines stored like: char** lines = malloc(...); lines[10] = &line1; lines[30] = &line2; lines[20] = &line3; Then when executing, it starts at `lines[0]', sees nops, gets to `lines[10]' and runs it, sees more nops, gets to `lines[20]' and jumps to `lines[10]'. All the while ignoring `lines[21]' and up.
    - abecedarius 10y ago
      Usually in 8-bit BASICs the lines would be stored consecutively (not in separate malloced segments) with each line starting with its line number. Yes, this meant that GOTO required a search. Memory was a really central design constraint on these systems. I don't know how closely MS's BASICA on the PC followed this model, but the PC's starting configuration had 16k bytes of RAM.
      - david-given 10y ago
        Here's a description of the file format used by BBC Basic: http://xania.org/200711/bbc-basic-v-format http://xania.org/200711/bbc-basic-v-format That's Basic V, which was the variant used on the ARM-based Archimedes, but it's the same file format as the 6502 machine Basics. Note that the line numbers used by GOTO and GOSUB were specially flagged --- this was so the RENUMBER command could find them. It also meant that computed gotos weren't renumbered... (Of course, BBC Basic had proper named procedures and functions with local variables, but all self-respecting Basics had to support GOTO and GOSUB.)
- webtechgal 10y ago
  Spot on - so line 30 would never get executed on that code, and a series of '1's will get printed, in an endless loop, until stopped with a Ctrl-C.
- Etheryte 10y ago
  What is "correct order"? You forgot to answer the actual question.
  - allenu 10y ago
    Sorry, it was ambiguous. I assumed the writer of the original code intended to execute them in the order of the line numbers and that was the "correct order". Otherwise, the line numbers are meaningless.
Iv 10y ago
It would only print "1"s. The thing is that basic programs were not entered through a 2D text-editor per rather line per line. You would type "LIST" to re-read the whole program you typed so far, with the lines in the correct order. Then, you would enter a line starting with a number. It would overwrite any existing line with the same number. Typically, a way to correct the program you wrote would be to type: 30 15 PRINT "2" (replace the line 30 by an empty line, and insert a line number 15)
- andyjohnson0 10y ago
  Just to add that some BASIC dialects had a RENUMBER or RENUM command that would change all line numbers and references to use a consistent interval. Without that, programs could become hard to modify due to the "gaps" between the lines closing-up.
  - DanBC 10y ago
    Which is one cause of the spaghetti: 17 GOSUB 5500
  - colejohnson66 10y ago
    Couldn't you just increment by 100? Or even 1000? Why did everyone use 10? Was it some interpreter limit that didn't allow line numbers above a certain amount (like 2^15 on a 16-bit CPU)?
    - tallanvor 10y ago
      Certainly, it would in part depend on the support of the interpreter, though. Realistically, incrementing by 10 was easy, and if you really needed more you could use goto to jump down and back (though obviously that's not nice for readability).
    - Klathmon 10y ago
      Providex (a basic dialect that my company still uses) has a soft-ish limit of around 52000 for line numbers. You can get around that with some flags, but its more of a pain than its worth. We tend to go by hundreds for programs, and we have a renumber command, but using it is the nuclear option because it will break goto line number references from outside programs (yeah, that's a very common thing in this language)
DanBC 10y ago
If you typed those lines, then issued a LIST command, the interpreter would return 10 PRINT "1" 20 GOTO 10 30 PRINT "2" You don't have to type LIST to reorder the lines, that just shows the re-ordering to you. If you didn't type LIST, but did type RUN (with the "unordered" listing) the interpreter would run each line in sequence of line number. If you ran out of line numbers you could sometimes RENUMber the listing. Here's Stackoverflow: This question is marked as a duplicate: http://stackoverflow.com/questions/2435488/why-basic-had-numbered-lines http://stackoverflow.com/questions/2435488/why-basic-had-num... Here's the closed question it's marked as a duplicate of: http://stackoverflow.com/questions/541421/why-did-we-bother-with-line-numbers-at-all http://stackoverflow.com/questions/541421/why-did-we-bother-...
- deleted 10y ago
  [deleted]
alblue 10y ago
It would print out a series of 1s. It is the same as if you had entered 10 PRINT "1" 20 GOTO 10 30 PRINT "2" The reason this is allowed is because it let you rewrite existing programs; if you later entered 10 PRINT "Hello World" It would replace the original line 10 and use this one instead.
bencollier49 10y ago
Not an especially valuable comment from me here, but the fact that people who are probably very technically literate can ask this question makes me feel really rather old.
- jhbadger 10y ago
  I remember explaining line-number based BASIC to a younger programmer once and he really couldn't get his head around the idea of GOTOs and GOSUBs based on line numbers -- "why wouldn't you just define functions?"
  - jerf 10y ago
    I remember the minor shock I experienced when writing programs without line numbers. I recall a couple of "good at programming whiz kids" never could make the transition and dropped the compsci major. I escaped the "permanent brain damage" that Dijkstra complained about that era of BASIC producing, but I understand where he's coming from now and don't begrudge him the slight hyperbole. It was a language where there were so many accidental complexities that there was virtually no prayer of someone penetrating through to the essential issues, using Fred Brook's definitions of accidental/essential. You're not learning anything useful while you're manually renumbering lines because you used up everything between 15-20 and fixing up the GOTOs. (I never had anything with RENUM support.)

webtechgal 10y ago

Well noted. I recall there also used to be a STEP command in the basic interpreter (basica and gw-basic) with which the line number increment could be set e.g. STEP 5 will auto-increment the line numbers by 5. (The default used to be 10.)