Kaleidoscope in BASIC

A superb graphic featuring numerous triangles to form a kaleidoscope of colour. Original program created in BBC BASIC for the Electron. Subsequently re-written to run on BB4W, then converted back to RISC OS BASIC to run on the latest ARM hardware to improve the graphic rendering quality.

The only deprecated section of the program is line 170 containing a ‘GOTO’ which ‘exits’ the inner FOR-NEXT loop – is there a better way of doing this?

Author’s name: unknown.

http://www.riscosbasic.uk/pics/K-scope.zip

The only deprecated section of the program is line 170 containing a ‘GOTO’ which ‘exits’ the inner FOR-NEXT loop – is there a better way of doing this?

Change the GOTO 170 to K%=7

Change the GOTO 170 to K%=7

That’s not hugely satisfying from a clarity point of view, though. The original code seems to have been:

100 FOR L%=1 TO 6
110   PROCcalcs
120   GCOL 0,RND(63)
130   IF S$="A" THEN K%=1: GOTO 150
140   FOR K%=1 TO 7
150     VDU29,XC%(K%);YC%(K%);
160     PROCtriangles
170     IF S$="A" THEN GOTO 190
180   NEXT K%
190 NEXT L%

(ugh!) which suggests that the aim was to loop once in the event that S$="A" is true.

I think I’d suggest this as a cleaner way to do it, which is a lot clearer as to the intent:

100 FOR L%=1 TO 6
110   PROCcalcs
120   GCOL 0,RND(63)
130   IF S$="A" THEN end% = 1 ELSE end% = 7
140   FOR K%=1 TO end%
150     VDU29,XC%(K%);YC%(K%);
160     PROCtriangles
180   NEXT K%
190 NEXT L%

The whole thing is still very much 1983, though. How many single-character variables can we stick on a line? :)

The whole thing is still very much 1983, though. How many single-character variables can we stick on a line? :)

I suppose it comes down to things you can do to optimise on a system with a (in modern terms) limited memory space and slow processor.
Never the less your tweak demonstrates that GOTO mostly isn’t required and as you say it made the intent less clear.

The whole thing is still very much 1983, though.

My programming is probably still very much 1983 too – because that’s what I’m thoroughly familiar with, and it works. Well – I’ve not used GOTO since well before 1983, and I often use meaningful variable, procedure & function names, but otherwise… (often, not always – anything of only very local and obvious relevance is liable to be a single character…)

Well – I’ve not used GOTO since well before 1983, and I often use meaningful variable, procedure & function names,

You’ve mentioned most of my criteria for decent BASIC there.

Comments, decent structure and multi-statement lines only where they improve clarity would be others. I’m sure that you’re doing them, too.

(often, not always – anything of only very local and obvious relevance is liable to be a single character…)

i, j, k… (or i%, j%, k%). S$ and its content isn’t immediately obvious in the above, though…

Aren’t the A%-Z% integer variables supposed to be faster in BBC BASIC? Important back in BBC Micro times to get the most out of some routines.

‘exits’ the inner FOR-NEXT loop – is there a better way of doing this?

Going with Steve is certainly best for this problem, but in general an early exit from the middle of a loop can most easily be done by putting it into a PROCedure and using ENDPROC. This ensures that the stack is cleared correctly, which will not happen with the original GOTO code. A very artificial example:

DEFPROCnextloop
 FOR i%=1 TO 10
  PRINT i%
  IF i%=5 THEN ENDPROC
  PRINT i%^2
 NEXT i%
ENDPROC

GOTO mostly isn’t required

Fixed that. ;-)

You’ve mentioned most of my criteria for decent BASIC there.

+1 indeed.

Aren’t the A%-Z% integer variables supposed to be faster in BBC BASIC?

Any advantage in ARM BBC BASIC is tiny, although it could be significant in BASIC II. In a reasonably tight loop there is even less, or no, advantage because of the way BASIC caches the values of variables. Something similar applies to PROC/FN names.

isn’t immediately obvious in the above, though…

Indeed, and the only thing that would have made me write anything like that would have been hitting memory limits.

DEFPROCnextloop
 FOR i%=1 TO 10
  PRINT i%
  IF i%=5 THEN ENDPROC
  PRINT i%^2
 NEXT i%
ENDPROC

But then it won’t compile. (unless you put the GOTO back)

< ducks quickly >

This ensures that the stack is cleared correctly, which will not happen with the original GOTO code.

Originally it would, I think, because the first GOTO skipped the FOR statement, while the second skipped the NEXT? In effect there was no FOR NEXT loop at all.

However, you’re correct that as presented at the start of this thread, with the first GOTO in the pair commented out, the stack would have got a bit confused.

As I said, ugh! :)

But then it won’t compile.

Compile? This is BASIC!

:)

Steve pointed out there were 2 GOTO statements. Not knowing what this section was doing I REMmed out the first GOTO and it still worked – bad idea obviously! Having looked at Steve’s example (no dreaded GOTOs) it is by far the easiest to understand.

GOTO statements are an abomination – I’ve looked at many of the earlier BBC BASIC programs using them and few seem to make any sense, and almost impossible to modify. Perhaps because memory was at a premium programmers avoided comments.

The remainder of the program reminds me of Jan Vibe’s numerous graphic offerings (make no mistake they were exceptional) but obscure variables and few comments make them difficult to edit.

Thanks for all your informative replies.

But then it won’t compile.

Wait… ABC can’t cope with multiple exit points? Why the hell not?

Something I do a lot in my functions is to bail at the first opportunity. As a wholly made up example, consider a function to extract the image reference from an HTML image tag:

• Input is empty? Then bail.
• Input doesn’t begin “<img”? Then bail.
• “src=” not found? Then bail.
• No quote character found after the “src=”? Then bail.
• No quote character found after that? Then bail.
• Extracted string in between is empty? Then bail.
• A space in the string (missing closing quote, got something else?)? Then bail.
• Finally, we have something. Don’t bail. ;-)

Those who dislike multiple exit points would have us suffer an twisted pile of nested conditionals simply to satisfy an entirely arbitrary perspective. Consider the first two cases – the function was called with no input or with something that isn’t an image tag. If this happens, then there isn’t the slightest bit of sense in attempting to run any of the rest of the function (even if that amounts to a big if block that is ignored). Simply be efficient and exit back to caller.

GOTO statements are an abomination

GOTO statements have their uses, but replacing any attempt at proper procedural programming isn’t one of them.

many of the earlier BBC BASIC programs using them and few seem to make any sense

You can blame everybody else for that. You see, back in the eighties it was fairly popular to have books that had you do various programming tasks, such as the Osborne books like “Write your own adventure game”.
Unfortunately, in order to sell, they have to use the most generic version of BASIC possible, with a few replacements depending upon the particular machine, for example I think it’s the Spectrum that used INK and PAPER to set up the screen colours.
Even more unfortunately, everybody else’s BASIC was utter $#!+, so while the BBC Micro could happily cope with decent procedural programs written clearly and concisely, what kids were taught (because of their s***ty Spectrums) was an unholy mess of GOTO and GOSUB that required photocopies scrawled upon with coloured felt tip in order to figure out what the hell was actually going on. Program flow was basically a giant bowl of linguine as experienced after a bottle of rosé.

Perhaps because memory was at a premium programmers avoided comments.

Yes, mostly that, but partly also that comments were an integral part of the program. Unlike, say, C or assembler where the comments only exist in the source, the BASIC is both the source and the executed ¹, so the language needs to spot the comments in order to ignore them. There was one machine that, upon reaching a comment, would read it byte by byte asking “is this the end of the line”? BBC BASIC has the line length as part of the information at the start (along with the line number) so with any luck it simply did some quick maths to hop over to the next line.

¹ BBC BASIC actually stores programs in memory and on disc in tokenised form, however it’s a simple two way process, so LIST will reproduce the original source even if it is tokenised in memory.

Yes, mostly that, but partly also that comments were an integral part of the program. Unlike, say, C or assembler where the comments only exist in the source, the BASIC is both the source and the executed, so the language needs to spot the comments in order to ignore them.

Although on RISC OS, BASIC programs loaded outwith the BASIC command line will (by default) have CRUNCH applied to rectify this.

For a properly structured program, the fact that BASIC caches things like the locations of FNs and PROCs after it’s seen them once will also help it skip some of the verbiage.

it’s a simple two way process

Most of the time. :)

Unlike the RISCBasic complier, the ABC compiler is not language-compatable with interpreted BASIC. So you should not be surprised if it fails to handle intermediate ENDPROCs.

For example ABC does not support LOCAL variables, only private variables, which fall out of context during PROC and FN calls unless included in those calls as parameters.

Since ABC seems to be locked away in a tin – who wrote RISCBasic?

But then it won’t compile.

Have you tested that? I have not, but my reading of the manual suggests that it should. Such exits are allowed within loop and conditional structures, but not in the body of the definition.

A good read of chapter 4 of the manual, “ABC v BASIC interpreter”, is instructive. The phrase “certain small differences” is not borne out by what follows. ABC does not compile ARM BASIC, but a very similar dialect of BASIC.

who wrote RISCBasic

Silicon Vision Ltd. The latest version 3.25 (1-Jun-1995) was StrongARM compatable so works well on VRPC. It is also very useful for syntax checking a BASIC programme.

Seems to be still active and run by foreigners all with the same surname (e.g. Shamina Naniadi).

Jan Vibe’s numerous graphic offerings (make no mistake they were exceptional) but obscure variables and few comments make them difficult to edit.

My recollection is that many (most?) of these were deliberately one-liners, so used all the tricks in the book to reduce size. Such brevity is a valid aim in itself, I think.

Logged in to answer the question – only to see Chris has beaten me by only a few minutes. So I’ll go one better and add “Brian Pearson” to his Silicon Vision answer.

Interesting point about VRPC – I wonder if I still have my copy of RiscBASIC? (I have a USB floppy drive, so if I do and it’s not an 800K disc, I can install it.)

Although on RISC OS, BASIC programs loaded outwith the BASIC command line will (by default) have CRUNCH applied to rectify this.

But only with BASIC$Crunch set for BASIC V, or has that changed recently?

help it skip some of the verbiage.

The CRUNCH keyword has this Note:

‘The interpreter has been optimised for fully CRUNCHed programs.’

‘exits’ the […] FOR-NEXT loop – is there a better way of doing this?

An alternative EXIT keyword would be nice, perhaps aimed at the type of loop EXIT FOR or even the level of nesting EXIT FOR 3. ;-)

Have you tested that?

Not with that simple program, No.

But, I am trying to comple a 188K Basic program with such multiple ENDPROCs and that will not compile.

The ABC reference guide written by Paul Fellows (November 1988) which runs to some 148 pages explains that the DEFPROC statement must be the first non-space object on a line, each DEFPROC must have one and only one ENDPROC marking the end of the procedure code. Arrays and indirect expressions are not permitted as a parameter (e.g. DEFPROC( ? &DEAD)). LOCAL variables are only in scope in the body of the procedure (defined by the DEFPROC/ENDPROC) any reference elsewhere including in any procedure calls made from the procedure in which the variable is defined LOCAL will use the global variable of the same name. Hence LOCAL variables are not restored from the stack but are simply private to the procedure. The manual says nothing about recursion.

No LOCAL error handling is permitted, all error handling throws away any LOCAL variables and stack usage and does not know the original line number.

But, I am trying to comple a 188K Basic program with such multiple ENDPROCs and that will not compile.

Correct. The manual explains that ABC cannot do this.