Boolean arrays in BBC BASIC

BBC BASIC treats Boolean TRUE and FALSE as &FFFFFFFF and &00000000, which is fine for the odd Boolean variable here and there – but fearfully wasteful of memory if you want a HUGE array of them. Yes, there are reasonably easy ways round this, but a proper Boolean array would be rather handy.

(Actually, proper byte arrays would be fairly nice too – although the ways around this using the ? indirection operator aren’t so bad.)

there are reasonably easy ways round this, but a proper Boolean array would be rather handy.

Basalt structures, and my Structs BASIC library, can do both byte array and bit array elements. A bit array element is handy for icon flags, for instance. These are not BASIC arrays, though.

Effective byte arrays are trivial to set up and use, as you suggest, but bit arrays are trickier and you need an efficient way to set and get a single bit in an arbitrary byte. This is pretty simple in assembly, but awkward in BASIC itself.

This is pretty simple in assembly, but awkward in BASIC itself.

Exactly. Back in 26-bit days I used to write assembly routines for precisely this sort of thing, but nowadays it’d be nice to have it in BASIC itself…

DIMBOOL bits%%(512,1024,1024) anyone?

Or even better

LOCAL bits%%()
DIMBOOL bits%%(x%,y%,z%,c%)…

Since in my proposal BOOL would only be for arrays, it could be just BOOL rather than DIMBOOL – but either way what token (or probably previously unusable combination of two tokens?) you’d use I don’t know.

BBC BASIC treats Boolean TRUE and FALSE as &FFFF and &0000

It doesn’t; TRUE=-1 FALSE=0

what token (or probably previously unusable combination of two tokens?) you’d use I don’t know.

prototype=DEF(STRUCT OF bit#(1023))
structure=NEW(prototype)
\structure.bit#(237)=1:REM set
\structure.bit#(237)=2:REM toggle
PRINT \structure.bit#(237)REM 0

The array is one-dimension. The ‘\’ is Basalt’s way of breaking into the program and can be read as “value of”.

If there were BASIC arrays then I think DIM bit#(512,1024,1024) and bit#(2,5,9)=1 would work syntactically.

It doesn’t; TRUE=-1 FALSE=0

Indeed. Silly. Corrected.

I’m not sure whether you can usefully put a Boolean into a floating point number though, so it’s arguably more useful to think of TRUE in particular as &FFFFFFFF rather than -1.

If there were BASIC arrays then I think DIM bit#(512,1024,1024) and bit#(2,5,9)=1 would work syntactically.

Nice. I wonder if there’s any chance anyone might implement it? Sadly, it’s utterly beyond my capabilities.

so it’s arguably more useful to think of TRUE in particular as &FFFFFFFF rather than -1.

It’s not!

TRUE is NOT FALSE i.e. all bits set, which as BASIC only has singed integers is -1. If you assign TRUE to a float is also -1 as there is only a signed conversion from integers to floats.

If we ever get 64 bit BASIC, TRUE will still be -1, but it wont be &FFFFFFFF !

Hmm. Depends whether an AArch64 BASIC would be crazy enough to have 64-bit integers as default.

If you assign TRUE to a float is also -1

Well, of course, since you can assign integers to floats. But it’s a daft thing to do, and useless unless what you actually want is -1, which is just introducing unnecessary confusion.

When you use integers in conditions (as though they were booleans), 0 is indeed FALSE, but anything other than 0 is treated as TRUE, not just -1. Even more confusingly, the same is true if you use a floating point variable like that.

(This is a potential trap for the unwary, where a% AND b% can be FALSE even though a% and b% are both TRUE.)

Like Stuart Swales, I rather hope that AArch64 BASIC would keep default integers as 32-bit. All sort of things would be liable to break if it changed to 64-bit integers.

I really like Steve Drain’s use of # for boolean variables – which would leave %% available for long integers should anyone ever really implement AArch64 BASIC, with any of these ideas.

Hmm. Depends whether an AArch64 BASIC would be crazy enough to have 64-bit integers as default.

As BASIC only has one type of integer variable, not having 64 bit integers on a 64 bit OS would leave it incapable of using any system call with a 64 bit int, e.g. memory pointers.

As BASIC only has one type of integer variable

There’s no reason why AArch64 BASIC should be thus limited. See my post just before yours.

There’s no reason why AArch64 BASIC should be thus limited. See my post just before yours.

Or even AArch32 BASIC…

Or even AArch32 BASIC…

How very true! And the Boolean arrays could be in both, too…

Steve Drain’s use of # for boolean variables

And so bang goes any hope of future convergence with other dialects of BBC BASIC. BB4W uses # for doubles, whilst & is used for bytes. Bytes would be more generally useful, and less wasteful as booleans (although the importance of Druck’s point about TRUE being -1 would suddenly be very clear).

but fearfully wasteful of memory if you want a HUGE array of them.

But, on the other hand, it’s a single LDR to retrieve the value. Byte and bit arrays need to retrieve, mask, shift…

And so bang goes any hope of future convergence with other dialects of BBC BASIC.

As far as I’m concerned, that horse has long since left the stable. For a start, the line numbering is different, so tokenised programs cannot be transported between the two, like, at all. It needs to be demoted to text, which might introduce some of its own issues.
Oh, and aren’t some of the token bytes different, too?

I wonder, does it use five byte reals or eight byte or what? The true BASIC itself is all over the place in this regard (depending on whether it’s plain BASIC or any of the FP-enhanced versions).

0 is indeed FALSE, but anything other than 0 is treated as TRUE, not just -1.

It helps to think of it as “FALSE” and “not FALSE”.
It also allows extended stuff like using/returning -2, -3, and so on. TRUE, TRUER, and TRUEST? ;-)

so it’s arguably more useful to think of TRUE in particular as &FFFFFFFF rather than -1.

It’s arguably better to think of it as -1 as that is not only independent of whatever word size may be in use, it’s also a lot faster to type.

that horse has long since left the stable

+1

It’s arguably better to think of it as -1

By definition the keyword TRUE returns -1. The result of a true logical expression is also defined as -1. BASIC casts freely between integer and float so nothing more can be said. How logical keywords such as IF interpret an argument is another question. ;-)

TRUE is any value where all bits are set. FALSE is all bits clear.

But, on the other hand, it’s a single LDR to retrieve the value. Byte and bit arrays need to retrieve, mask, shift…

Indeed they do, which is horribly slow. But would allow the most humongous arrays, which is my need of the hour. I don’t expect to see any implementation really of course, much less on any timescale of any use to the current project. Heigh ho. Byte arrays would be nice, but I can implement those with indirection operators easily enough, and am in process of doing so.

And so bang goes any hope of future convergence with other dialects of BBC BASIC. BB4W uses # for doubles, whilst & is used for bytes.

As you’ve obviously realized, I don’t know any other dialects of BBC BASIC. I don’t care what the syntax is anyway. If anyone actually implements any of this I shall be grateful, whatever syntax they decide upon.

TRUE is any value where all bits are set. FALSE is all bits clear.

This is why it is very important to remember in BASIC or any other language that the TRUE value should only ever be used in assignments and never in caparisons.

i.e. a function can return TRUE, but you should never check IF something = TRUE THEN...

Where as FALSE can be used for both.

This is because FALSE is always zero regardless of what type the variable is, but literal TRUE may have a value dependant on the type of the variable.

It’s much better to check if something isn’t FALSE

e.g. IF something <> FALSE THEN... or just IF something THEN...

Sorry, I hope this is not rude, but I am amazed at all this fuss over battles lost and won many decades ago. First, you need a separate datatype for Booleans (Pascal’s big lesson). Second you need a clearly defined coercion from other types to Booleans, if you want to be able to express things like if a then b = (c and d) or e when the values in question may not be themselves Booleans (Icon’s big lesson). Third, you need a proper discrimination between bitwise and logical operations (& versus && etc in C) which should be eager and lazy respectively.

As a spectator on the sidelines I am beginning to think that Dijkstra had a point. :).

I am amazed at all this fuss over battles lost and won many decades ago.

Hear, hear! This is a horrible mess in BBC BASIC; the question is how to make the best of a bad job.

This is a horrible mess in BBC BASIC

I am just amazed that so many programmers could write tens of thousands of programs with such a mess to work with.

On the other hand, after 40 years, many are still getting in a twist about booleans in BASIC.

I follow TDWTF and the misuse of booleans is a regular subject in all sorts of languages.

the misuse of booleans is a regular subject in all sorts of languages.

I don’t doubt that for a moment. Being as what my only languages are Fortran, PDP8 assembler, 6502 assembler, Algol, Cobol, 3790 assembler, Pascal, BBC BASIC & ARM Assembler – the last two the only ones I’ve used in the last two decades – I wouldn’t pretend to know.

I am just amazed that so many programmers could write tens of thousands of programs with such a mess to work with.

Me amongst others. Doesn’t mean the handling of Booleans is any good though. One manages despite the mess.

To be honest, I don’t give a damn about using 32 bits where one would do – for stand alone boolean variables. It’s those humongous arrays where the issues arise. So now I’m using 8 bits where one is relevant. So be it, but it does limit the size of my humongous arrays. I ain’t going to start farting about making workarounds. Life’s too short.

Doesn’t mean the handling of Booleans is any good though.

Were IF and the similar keywords to only work with strictly boolean values ¹ I think there would be less of a problem. The simplification to ‘non-zero’ for ‘true’ makes sense when every byte matters. However, I have seen very similar situations reported for other languages, so it is not only BBC BASIC.

¹ ‘true’ is -1 and ‘false’ is 0 whether integer or float