BASIC functions to save/restore all variables
Rick Murray (539) 13872 posts |
Yup. Swipe-type guessing what I meant to say…
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 With explicit declarations the second would be faulted and you’ll be able to spot and fix the typo. 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.
Yup. That was the other thing at the top of my code. ;) |
Steve Pampling (1551) 8188 posts |
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. Would it? |
Steve Pampling (1551) 8188 posts |
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. |
Rick Murray (539) 13872 posts |
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). |
Colin Ferris (399) 1819 posts |
Good idea – but you need a prog to check that you have included all variables :-) |
GavinWraith (26) 1563 posts |
There are no global variables in Lua. All variables are either local to a chunk (and so require a |
Chris Hall (132) 3567 posts |
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. |
Matthew Phillips (473) 721 posts |
Coming rather late to the discussion, picking up something Paolo said:
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. |
Steve Pampling (1551) 8188 posts |
What about nested code? Passed down as per BBC BASIC or not passed down? |
Rick Murray (539) 13872 posts |
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…
So very much this. |
Clive Semmens (2335) 3276 posts |
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. |
Steve Pampling (1551) 8188 posts |
Almost. Behaviour when you don’t follow that guideline will be implementation dependent, and probably not what you want. |
Rick Murray (539) 13872 posts |
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. (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…)
True, but that implies there’s a viable alternative. |
Clive Semmens (2335) 3276 posts |
My point exactly. In Subroutine Supermarket, called from ancestor France you get French stuff. Called from ancestor England you get English stuff. |
Rick Murray (539) 13872 posts |
Normal languages handle that by passing a parameter “stuff” that determines which. It shouldn’t depend on the progenitor. You’ll note, the BASIC manual does not mention this. By accessing LOCAL variables in a subfunction, we’re already straying into undefined territory. |
Rick Murray (539) 13872 posts |
Interestingly, the BBC B User Guide said:
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. |
Steve Pampling (1551) 8188 posts |
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. |
Paolo Fabio Zaino (28) 1882 posts |
@ Matthew
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.
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. |
Paolo Fabio Zaino (28) 1882 posts |
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 |
Rick Murray (539) 13872 posts |
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…
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. |
Paolo Fabio Zaino (28) 1882 posts |
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).
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.
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). |