BASIC functions to save/restore all variables

It should have read “declared before use”.

Yup. Swipe-type guessing what I meant to say…

once a programme is working perfectly

Clearly you aren’t a programmer.

There’s no such thing as a perfectly working program.

And, anyway, explicit declarations helps to avoid stuff like this:

sillyvariablename% = FALSE
IF (something something) THEN sillyvariblename% = TRUE

With explicit declarations the second would be faulted and you’ll be able to spot and fix the typo.
In BASIC? It would make a new variable and set it to TRUE. Whether or not this is easy to find and fix depends upon what exactly the code is doing. If the setting to TRUE only happens in one place, easy to track down. But if it’s a variable that is changing and you’re getting unexpected off-by-n issues, well, you’ll need to start looking at everything that fiddles that variable….and then risk missing it if you typed it in as the search string (because a typo wouldn’t match).

This isn’t a contrived example, I’ve fixed some programs that “didn’t behave quite right” that was purely down to spelling errors in the variables.
The original programmer couldn’t spot it, but then programmers don’t tend to be good at finding their own bugs because they are so used to the code that they speed read it.
That’s why the Rubber Duck Method works (and, yes, there’s a little yellow duck sitting on my monitor just in case).

there was also Option Strict

Yup. That was the other thing at the top of my code. ;)

Part of me wonders how many programs would break because the author assumed that declaring a variable within a subroutine without stating LOCAL would default to global.

None. The variable would be global.

Would it?
If the suggested re-write “helpfully” assumed a variable that didn’t previously exist and was now declared in a subroutine was only required LOCAL then what?

There’s no such thing as a perfectly working program.

An almost perfect program will cope with all the idiotic things a user does, and then along comes a better idiot.

The perfect program would cope with the bigger idiot, unfortunately you then have the perfect idiot.

then what?

Loads of programs will stop working.

I have come across, and do myself the definition and setting up of global variables within a function like PROCinitialise, to have everything neatly compartmentalised (and to not begin the program with lots and lots of definitions).

Good idea – but you need a prog to check that you have included all variables :-)

There are no global variables in Lua. All variables are either local to a chunk (and so require a local declaration) or are keys in a table. When a program starts up a special table, _G, is set up to provide an initial environment. Its keys behave like global variables, but the user can transfer this privilege to whatever table she chooses. If a variable which has not been defined occurs in an expression the default behaviour is that it has the value nil. But the user can change this behaviour, to raise an error, for example. So how the Lua interpreter behaves (e.g. making the values of a table read-only, or controlling how often garbage collection happens, or having a local variable trigger an action when it goes out of scope) can be controlled from within a program. Behaviours can also be locked. Very useful for sandboxing.

I have come across, and do myself the definition and setting up of global variables within a function like PROCinitialise, to have everything neatly compartmentalised (and to not begin the program with lots and lots of definitions).

Exactly what I do too.

The other principle I use is that if I have a chunk of code doing something that occurs in several places, I wrap it in a ‘DEF PROC .. ENDPROC’ wrapper and call it in each place as a procedure with no parameters. Then when I find it is doing the wrong thing, I only have to correct it once.

Coming rather late to the discussion, picking up something Paolo said:

I’ll admit that the BBC BASIC’s concept of LOCAL is one of the most confusing I have ever seen (and I code in many, many programming languages)…

As far as I remember, Perl has exactly the same concept of “local”. But it is now frowned upon and modern Perl uses “my” instead. One of the few cases where I prefer PHP to Perl is the way all variables in PHP are scoped to the function, unless you explicitly declare them global. Saves a lot of hassle declaring “my $this”, “my $that” etc.

Although BBC BASIC was advanced (compared to other 8-bit BASICs) in having local variables and named procedures, it still tends to lead to people relying on heavy use of global variables, and local variables being accessed from child functions, which can make properly separating and testing code challenging. The main reason for this is, I think, the lack of complex data structures, making it hard to pass more complex data as a parameter to a function or procedure.

the way all variables in PHP are scoped to the function, unless you explicitly declare them global.

What about nested code? Passed down as per BBC BASIC or not passed down?

What about nested code?

Local means local. A nested function is not local.

Note that, like C (etc) this can be block local, not just entire functions.

You pass locals to nested functions either by passing as a parameter, or by using the use() construct.

When you’re used to proper locality, BASIC is…weird. Luckily I grew up with BASIC so it’s not an entirely alien concept, but…

it still tends to lead to people relying on heavy use of global variables, and local variables being accessed from child functions

So very much this.

LOCAL, like every other keyword, means whatever it means in the particular language you’re using.

Local in particular obviously originates in the geographical term “local”, and that’s far more like the way BBC BASIC uses the word than the way other languages do. If something is local to France, that means it’s not something you’d find in England – but it certainly doesn’t mean it’s not something you’d find in Clermont Ferrand…

Either usage is fine. You just have to know the meaning of keywords in the particular language you’re using.

You pass locals to nested functions either by passing as a parameter,

Almost.
“You should pass locals to nested functions by passing as a parameter” is a better, more accurate description.
I think that probably covers all languages so that you have visibility in the parameters available to the function before you enter, as well as when you’re in it.

Behaviour when you don’t follow that guideline will be implementation dependent, and probably not what you want.

If something is local to France, that means it’s not something you’d find in England

It’s a bit of a tenuous example, bit let’s go with it.

If a Frenchie comes and visits the UK, they’re not going to find all the stuff they’re used to lining the shelves of British supermarkets.
With the exception of popular exports that turn up in Waitrose, French stuff is in French supermarkets and Brit stuff is in British supermarkets. Both are local to the country. Changing country doesn’t change what “local” means.

(I’ve had to wait twenty years for cheddar to make an appearance… Other stuff I get from Amazon, but Brexit has greatly complicated things…)

is a better, more accurate description.

True, but that implies there’s a viable alternative.
In most languages, said alternative is the (ab)use of globals, which I’d hope would be stamped upon in week one of any course on programming.

With the exception of popular exports that turn up in Waitrose, French stuff is in French supermarkets and Brit stuff is in British supermarkets. Both are local to the country. Changing country doesn’t change what “local” means.

My point exactly. In Subroutine Supermarket, called from ancestor France you get French stuff. Called from ancestor England you get English stuff.

Normal languages handle that by passing a parameter “stuff” that determines which. It shouldn’t depend on the progenitor.
Thus, stuff is local to the routine (country) to which it belongs, until such time as it explicitly chooses to share it.

You’ll note, the BASIC manual does not mention this. By accessing LOCAL variables in a subfunction, we’re already straying into undefined territory.

Interestingly, the BBC B User Guide said:

All formal parameters are local to the procedure which means that their value is not known to the rest of the program. […] Global variables are known to the whole program, including procedures, whereas local variables are only known to those procedures in which they are defined and to procedures within that procedure.

The part I’ve emphasised has been omitted from the various ARM era BASIC manuals that I have in PDF form. Maybe it was something that was planned to be fixed…..until it was noted how much stuff would break.
(witness the many discussions about the ABC compiler not doing LOCAL “correctly”)

The part I’ve emphasised has been omitted from the various ARM era BASIC manuals that I have in PDF form. Maybe it was something that was planned to be fixed…..until it was noted how much stuff would break.

Whatever the reason for not making the code change, the documentation needs altering (reverting) to the version that describes the reality.

Deprecation notices could be issued if the code change was planned for some future date.

@ Matthew

As far as I remember, Perl has exactly the same concept of “local”.

Correct, however the keyword “my” was introduced with Perl 5 (IIRC 1993 or 1994), which is also the most popular Perl release (and, incidentaly, the one we have on RISC OS), so, while technically correct, Perl had a much faster and congruent evolution than BBC BASIC.

it still tends to lead to people relying on heavy use of global variables, and local variables being accessed from child functions, which can make properly separating and testing code challenging. The main reason for this is, I think, the lack of complex data structures, making it hard to pass more complex data as a parameter to a function or procedure.

I agree and I’d add that part of the problem is also the lack of a STATIC modifier, which would help a lot handling things in slices on a NULL event for example.

In more general terms, however, BASIC lack these elements because it was designed in a time were systems were not capable of dealign with programs as complex as a WIMP Application can be (complex for the time obviously). What is kinda annoying (I don’t mean this is a rude way!), in the other hand, is that BBC BASIC is the default language for RISC OS, but it did not develop well with the WIMP world.

Normal languages handle that by passing a parameter “stuff” that determines which. It shouldn’t depend on the progenitor.

Absolutely true. The issue is that the value is INTRISICALLY depended on a progenitor, not esplicitely set so. Which is so prone to bugs (and that also makes it very difficult to write tests for), which sould be avoided at all costs.

In !launchpad, to make the code rock solid, I had to introduce the concept of prefixes to variable names, to avoid any possible random collision between a traditional idx% (or i% for some folks!) caused by a progenitor that may be using the same name.

Given that is quite common to reuse same names for non-foundamental variables (and some folks also for every variable), you can see how prone to problems this can become.

The prefix solves the issue, but makes the code harder to read, ‘cause it’s kinda like C++ function name mangling (althought if not this bad), but there is really no other way to ensure clear separation between procedures and functions in BBC BASIC.

Does this makes code slower? absolutely not, !Launchpad is proof. Architecture is what makes code fast or slow, so IMHO BBC BASIC should be fixed. Fixing the issue may actually improve robustness of older applications too and if they really need to have access to a progenitor local value, that could be added as a parameter.

Just my 0.5c

but it did not develop well with the WIMP world.

Structures.

All this block%?…block%!…nonsense is mind-melting when you have to deal with it.

I think programmers of a certain epoch all wrote a bunch of library functions that they never touched again, because, no, I don’t ever again want to have to deal with nonsense like:

block%?12=7   : block%?13=2  : block%?17=7 : block%?15=0
block%!16=140 : block%!20=44 : block%!24=0

So, like perl, it was write-only code.

How much nicer it would have been to have structures. Oh, and given the Wimp, the ability to cast a block of memory to a structure (as I really wouldn’t expect BASIC to support the insanity that is “union” when it comes to Wimp blocks).

But, alas, it wasn’t to be. If you want structures, there’s the other sort of BBC BASIC…

Does this makes code slower? absolutely not

Well, technically… ;)

Anything outside of the built in variables (A%-Z%) will incur a speed hit that would also depend upon the length of the variable name. But we’re talking _nano_seconds these days, and as you point out, a poor algorithm will be bad no matter what the variables are called.

All this block%?…block%!…nonsense is mind-melting when you have to deal with it.

I agree, and make people waste their time with searching, reading and re-reading their code. In other words what I have mentioned in another thread, coding on RISC OS is extremely unproductive for 2023 (some would refer to it an an anti-pattern even).

How much nicer it would have been to have structures.

Indeed and Classes too, private and public members, lambdas, C calling-conventions to use C buitl function and a VM that processes the produced byte code without us having to slice up our functions and all the other great things that has come over the last 30 years. But in all honesty, we have a decent C++ with GCC, so I am good. BASIC is not longer a language that I use.

I used it for Launchpad to see what was possible in 2023, but as we mentioned here on multiple comments, it’s still in the late 80s stage, so nothing I am considering worth of using anymore.

Anything outside of the built in variables (A%-Z%) will incur a speed hit that would also depend upon the length of the variable name. But we’re talking _nano_seconds these days, and as you point out, a poor algorithm will be bad no matter what the variables are called.

Indeed. BTW, just for the sake of the chat, let’s not forget the caching game and branch predicition, so things may not be as “linear” (even for an old school interpreter). A variable that on paper should be slow, because it keeps getting used becomes faster than an A% that needs to be loaded from memory (even 100s of times faster).