BASIC regret – no early exiting AND/OR

Bestest evs would be short-circuited binops… which could be && and || because why not.

&& is easier than || of course, because early failure is easier than early success (that is not intended to be a philosophical maxim).

[mud]

Yeah, in this case. But I could contrive a three-part dependency and you’d have to add a predicated CONTINUE in there too.

Bestest evs would be short-circuited binops… which could be && and || because why not.

For BBC BASIC you might have some problems with interpreting them and avoid corner coonditions, but not impossible I expect. Not possible with Basalt, but the LOGAND function does the job.

&& is easier than || of course

Why so? I found them equivalent, and the BASIC work-arounds are quite symmetric.

you’d have to add a predicated CONTINUE in there too.

No need. BASIC does CONTINUE with an early ENDWHILE UNTIL0 or NEXT.

Why so?

No I was wrong.

BASIC does CONTINUE with…

UNTIL0 yes. The other two, no, not always.

Since BASIC has AND and OR, it would be logical to use AND_THEN and OR_ELSE like DEC Pascal or AND THEN and OR ELSE like Ada. Introducing C-/Java-like operators in BASIC would be…somehow alien.

Sadly ELSE has magical qualities and can’t be overloaded in this way.

In fact it’s worse than that, you can’t even have byte value &8B in a string after an IF statement. :-(

Little-known ever-present obscure bug #1.

Little-known ever-present obscure bug #1.

But it has been documented as a WARNING in my BASIC StrongHelp manual for years.;-)

ELSE … can’t be overloaded in this way.

If you are going to the trouble of developing BASIC, then this bug could be dealt with at the same time.

If you are going to the trouble…

Says the guy who has clearly gone to a lot of trouble.

Do you have a warning against CALLaddr – that it should always be CALLaddr,A%? :->

If you mean the danger of calling MOS routines in the address range &FFCE-&FFF7, then yes. But that is documented in the BASIC manual.