White space between INSTR and it's paren "(" causes (SOLVED)
Aug 1, 2024 5:49:31 GMT 1
Post by Pjot on Aug 1, 2024 5:49:31 GMT 1
Hi Roger,
LOCAL means "local scope", so the variable name only is valid and visible (lexically) within a SUB or function. That means you can use that same name again in another SUB or function, like the documentation states. Especially when using non-explicit names, like "a" or "s1$", it helps to isolate the variable names between functions.
In the end, it comes down to the "Recommended Programming Practice" in case of global variables, the kind of variables which we are not supposed to use. I am the first to admit that I myself am a sinner against that recommended practice. Generally speaking, it is just convenient to have a global variable, saving a lot of fuzz of passing values, string, arrays etc to functions. That's why BaCon has a GLOBAL keyword.
But it always is "bad" to use global variables. There are many discussions and remarks about this on the internet, for example here, here and here. Summarized, they come down to issues with clarity, name clashes with local functions and 3rd party libraries, issues with unit testing and multithreading (yes, you can use multithreading in BaCon as well, using OpenMP).
Some programming languages do not even allow using globals at all (like Java).
Point is: if we would avoid using global variables, there is no issue with variable shadowing in the first place.
But if we do use global variables, then you'll find countless discussions on the internet about variable shadowing, whether this is "good" or "bad" and so on. Let's not repeat those discussions here.
As mentioned, I myself ran into some of those issues. After a while, even I started to understand why those recommended practices exist. And in spite of me knowing better, I still use global variables up to this day. But that's only because I am stupid.
To force at least a little bit of clarity in this whole mess, BaCon simply blocks variable shadowing altogether.
Edsger Dijkstra, a fellow countryman, once said: "It is practically impossible to teach good programming to students that have had a (prior) exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Let's at least try to prove him wrong
Best regards
Peter
Maybe I'm misunderstanding something key here, but without shadowing what is the point of having a variable be "LOCAL"?
LOCAL means "local scope", so the variable name only is valid and visible (lexically) within a SUB or function. That means you can use that same name again in another SUB or function, like the documentation states. Especially when using non-explicit names, like "a" or "s1$", it helps to isolate the variable names between functions.
I haven't inspected BaCon's emitted "C" code but the difference between a GLOBAL and LOCAL variable might be the appending to a variable identifier a unique string that changes from SUB to SUB and FUNCTION to FUNCTION?
That does not happen at all.
In the end, it comes down to the "Recommended Programming Practice" in case of global variables, the kind of variables which we are not supposed to use. I am the first to admit that I myself am a sinner against that recommended practice. Generally speaking, it is just convenient to have a global variable, saving a lot of fuzz of passing values, string, arrays etc to functions. That's why BaCon has a GLOBAL keyword.
But it always is "bad" to use global variables. There are many discussions and remarks about this on the internet, for example here, here and here. Summarized, they come down to issues with clarity, name clashes with local functions and 3rd party libraries, issues with unit testing and multithreading (yes, you can use multithreading in BaCon as well, using OpenMP).
Some programming languages do not even allow using globals at all (like Java).
Point is: if we would avoid using global variables, there is no issue with variable shadowing in the first place.
But if we do use global variables, then you'll find countless discussions on the internet about variable shadowing, whether this is "good" or "bad" and so on. Let's not repeat those discussions here.
As mentioned, I myself ran into some of those issues. After a while, even I started to understand why those recommended practices exist. And in spite of me knowing better, I still use global variables up to this day. But that's only because I am stupid.
To force at least a little bit of clarity in this whole mess, BaCon simply blocks variable shadowing altogether.
Edsger Dijkstra, a fellow countryman, once said: "It is practically impossible to teach good programming to students that have had a (prior) exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Let's at least try to prove him wrong
Best regards
Peter