Weird BASIC is weird

Line numbers are pretty much a non issue unless you’re stuck in the mindset of using GOSUB and GOTO.

Just to ram the point home with an industrial pile driver…

REM >fudgelinnum
REM
REM A little demo regarding BASIC's line numbers
REM
REM Thrown together by Rick, 2019/04/29
REM

ON ERROR PRINT REPORT$+" at "+STR$(ERL) : END

infile$  = "fudgelinnum" : REM Input file (tokenised BASIC)
outfile$ = "fudgemunged" : REM Output file (will be overwritten)

REM Alloc space for the program and load it in
if% = OPENIN(infile$)
fsize% = EXT#if%
DIM buffer% fsize%
SYS "XOS_GBPB", 4, if%, buffer%, fsize%
CLOSE#if%

REM Process the program to fudge the line numbers
ptr% = 0
end% = FALSE

REPEAT
  REM Get initial <CR>
  byte% = buffer%?ptr%
  IF (byte% <> 13) THEN ERROR 17, "BASIC program corrupted at +"+STR$(ptr%)

  REM EOF?
  ptr% += 1
  byte% = buffer%?ptr%
  IF (byte% = 255) THEN end% = TRUE

  IF NOT end% THEN
    REM Set line number to 1
    buffer%?ptr% = 0 : ptr% += 1 : REM Zero high byte of line number
    buffer%?ptr% = 1 : ptr% += 1 : REM Set low byte of line number

    REM Get line length
    byte% = (buffer%?ptr% - 3) : REM Includes line number/length bytes

    REM Skip ahead
    ptr% += byte%
  ENDIF
UNTIL end%

REM Save it
SYS "XOS_File", 10, outfile$, &FFB, , buffer%, (buffer% + fsize%)

END

Save it as “fudgelinnum”, set CSD to where it is, run it.
A copy called “fudgemunged” will be created, with every line set to be line #1. Run that, it’ll do exactly the same thing.

Maybe nemo or Steve know about some little quirk that this could upset – but generally speaking if you don’t use line numbers, they’re just not an issue.

When I used to use Edit to write BASIC, I had it set to strip line numbers. When I use Zap, line numbers exist (different method of dealing with BASIC), but I tend to tell Zap to just hide them. I’ve not had to concern myself with line numbers in BASIC since, oh, 1988 or so.

I don’t. Line numbers are pretty much a non issue unless you’re stuck in the mindset of using GOSUB and GOTO.

RESTORE ?

RESTORE ?

RESTORE +0

:-)

How many people really use RESTORE n? Surely that’s as much an anachronism as GOTO and GOSUB? (RESTORE +/-n is better, as is RESTORE DATA. Not that I use any of them very often.)

Presumably you’re having to check every byte for nested FORs so you can find the matching NEXT, which may be a comma, and which may be sooner than you’d think due to named NEXT vars?

Yes, indeed. One of the requirements of Basalt is that programs are ‘well-formed’, ie FOR NEXT are matched and have single control variables. Also, my version does not do float control variables. Using an enclosing IF ENDIF is way faster, but syntactically less satisfying. It was implemented more as an exercise than for real use, and I have never done so. ;-)

Maybe nemo or Steve know about some little quirk that this could upset

Error reporting is a little tricky without line numbers.

RESTORE +0 and RESTORE +/-n

Just to clarify, RESTORE in this context can only be followed by +. The offset is the number of physical lines, without regard to line numbers. An offset of 0 or negative is the same as 1.

Error reporting is a little tricky without line numbers.

;-) Thank you for spotting the obvious bright pink elephant in the room.

Line numbers aid debugging.
But that’s about it, these days.

Heck, line numbers are so unimportant that BASIC will only report it by itself if you’re running from the command line. Otherwise it’s just “Mistake” or whatever with no line number quoted…

Error reporting is a little tricky without line numbers.

The first line of my BASIC progs is always something like this:

ON ERROR PRINT REPORT$ + " at line " + STR$(ERL): PROCclose: END

The first line of my BASIC progs is always something like this:

Mine is most often:

ON ERROR ON ERROR OFF:OSCLI"ReportError T":END

Thank you Martin. ;-)

A copy called “fudgemunged” will be created, with every line set to be line #1. Run that, it’ll do exactly the same thing.

Yes… There’s a surprising amount of stuff like this out there. The RISC OS source tree contains a lot of files where the line numbers are all zero, as I recall. I think they’re generated by a version control tool of sorts.

Or, as someone wrote in a manual a while back…

  Line numbers
  ------------

  BASIC's interpreter (as opposed to its tokeniser) is surprisingly relaxed
  about the use of line numbers if no reference is made to them (ie. if there
  are no "GOTO" or similar commands in the program).  Duplicate line numbers
  are possible, as are non-sequential numbers (such as lines appearing, and
  being executed, in an order like 10, 30, 20, 40) -- examples have even been
  seen where all the lines are numbered zero.

10 LIBRARY"uggh"
20 PROCdoodah
30 END
40
50 PRINT"Oh god"
60 ENDPROC

10 REM uggh
20 DEFPROCdoodah
30 GOTO 50
40 nope
50 PRINT"really, nope"
60 ENDPROC

And therefore

10 REM There's better ways of doing this
20 PROCcallback(1,10,60)
30 PROCcallback(90,100,70)
40 END
50
60 =X%*10
70 =X%-89
80
90 DEFPROCcallback(L%,H%,G%):LOCALZ%
100 FORZ%=L%TOH%
110  PRINTFNcallback(Z%,G%)
120 NEXT
130 ENDPROC
140
150 DEFFNcallback(X%,G%):GOTOG%

“But nemo! You can’t have line numbers as parameters because renumbering wrecks it!”

Weeeeeeeeell…

I think I know why I’ve never crashed into any of these quirks: I never try to do daft things just to see what happens.

Perhaps I should sometimes. It’s not as though I avoid doing daft things in other areas of life.

Weeeeeeeeell…

I suspect the use of ™.

Line numbers aid debugging.

I rather think they are essential. You may not use BASIC TRACE, but ReportTrace is quite handy, and Throwback relies on them.

I rather think they are essential. You may not use BASIC TRACE, but ReportTrace is quite handy, and Throwback relies on them.

Well, wouldn’t it be nice if such a thing was possible for languages that don’t have any concept of line numbers, like assembler or C…oh… wait…

I feel I may regret this question, but what editor is nemo using?

but what editor is nemo using?

I don’t think it has a name. It is one that he created himself in a language that he developed for the purpose of expressing perfect code. It’s a tonal language designed to represent pure thought, and as such any transcription into mere characters and symbols will lose so much meaning as to be relatively useless. You cannot even print out a disassembly of the program because of long complicated stuff that basically boils down to a version of Heisenberg’s uncertainty principle; suffice to say that his editor and his version of RISC OS interact in a symbiotic manner. That’s why he hasn’t blessed us with any of his goodies. They wouldn’t work. Our inferior brains just aren’t up to it. The best we can manage is to look at animated GIFs and think “oh pretty”.

Nemo, do you have any plans to release the software in your screenshot?

Nemo, do you have any plans to release the software in your screenshot?

I’m fairly sure that the software in Nemo’s screenshot, far from being anything “special”, is Zap in BASIC mode with the button bar enabled.

Indeed, that’s just Zap.

The clever wheeze was getting BASIC to accept tokenised line numbers as parameters, and the rather intractable problem of how you’d persuade the tokeniser to know when you meant a line number and when you meant some other integer. Some other syntax would be required.