GLOBAL depends on statement's position in code, not executio

[Chris Iverson]

GLOBAL seems to function as a compiler directive instead of an executable code statement, and this causes global data to unexpectedly not be visible in other scopes.

More specifically, GLOBAL variables seem to only be available to code placed after the GLOBAL statement in the file when going line-by-line, regardless of how the order of execution would make the global visible to previous code.

In the following code, I would expect all code to be able to retrieve the value of the global variable successfully:

gosub [setGlobal]
print myValue

call mySub1
call mySub2
end

Sub mySub1
   print myValue
End Sub

[setGlobal]
global myValue
myValue = 12
return

Sub mySub2
   print myValue
End Sub

However, if you actually execute this code, you get the following:

12
0
12

The SUB that executes after the GLOBAL is defined, but is defined before the GLOBAL variable in the file, does not see the GLOBAL variable's value properly. This is not how I would expect a variable declared GLOBAL to behave.

[Brandon Parker]

While I do agree that this is interesting behavior, I would also add that the creation of Global variables from within Subroutines/Functions is generally not a good idea. IMO it is a result of poor programming practices.

Unlike NoMainWin where the help file states that it just has to be "somewhere in the program source code", the help file does not specify that Global variables can be created anywhere, and thus I have always understood that Global variables should be created at the start of the code. Maybe I read that somewhere or it was just some intuition from previous experience...

Since any Global variable is Global in nature, it should always just be created at the start of the program since future updates might create a code that relies on a variable being Global and already created. I just never understand the logic for waiting to create a Global variable until it is used by what is, at the time, the first piece of code that uses it.

Always creating Global variables at the start of the program eliminates this type of strange behavior.

On a side note, I checked the Struct implementation, and it does not appear to exhibit the same behavior as the Global implementation. Which now that I think of it I am sure I would have seen an issue with it previously if it did.


{:0)

Brandon Parker

[Chris Iverson]

To each his own, I guess. I prefer to separate the business logic out from initialization, wrapper, and skeleton code. I don't want someone to have to dig through hundreds of lines of setup code to find the actual logical start of the program.

That's why we have functions, subroutines, and gosubs in the first place. To organize snd separate code into logical chunks. If that's not gonna work properly, they may as well not be there at all.


You'll note that, the way I set it up, the first thing that happens IS the globals being defined. I actually agree with you there; they should be defined first. Waiting until later in the program to define them can easily lead to trouble.

However, I find my implementation (that is, putting them in a gosub and calling it first) and your suggestion(actually have the global definitions physically at the top of the file) to be logically the same. I feel they should, therefore, behave the same.

[Brandon Parker]

I agree, it's definitely strange and the behavior should not occur. At least, one would think it would affect the Struct similarly. This is not the first time we have seen something similar; arrays have some quirky stuff with their in-code order as well.

I would presume, by the way it is acting, that the runtime engine is incorrectly ascertaining that the Global variable has not been instantiated yet. That's the point I was trying to make above when I referenced the NoMainWin keyword vs. the Global keyword. Since it does not appear that LB is treating Global variables as compiler directives and it does appear they are being treated more like lines of code, this is my thinking; the runtime is just thinking that since the Global instantiation is below mySub1 it has not been created yet. This of course is completely wrong; this we agree on. I just think the underlying issue is akin to why one normally includes function declarations in the header file for C++ and similar languages; the compiler needs to know about them; otherwise, it is going to bark at you if a function in the code is called prior to the compiler having parsed that section of code during the compilation process.

I also just think that instantiating Global variables in a Subroutine/Function is not necessarily a good habit from a computer science perspective.

Maybe Carl will chime in and give us the real underlying reason for what is being observed.


{:0)

Brandon Parker

[Carl Gundel]

Defining a global should be a compile time effect. If it doesn't work that way, then I should fix it.

[Brandon Parker]

Jul 29, 2021 15:10:52 GMT -5 Carl Gundel said:

Defining a global should be a compile time effect. If it doesn't work that way, then I should fix it.

It seems to work as expected in LB5 (lb5x64-352) ...

If you want to resolve the issue in LB4.5.1 then I would be more than happy to see some of our other issues that have been discussed recently resolved as well if we could get them taken care of.


{:0)

Brandon Parker

[timur77]

Jul 28, 2021 21:49:30 GMT -5 Brandon Parker said:

... I have always understood that Global variables should be created at the start of the code. ...


{:0)

Brandon Parker

I also!

[Dennis]

I always define all the Globals at the start where they can be readily seen...