Confused about LOCAL....

[webmasterpdx]

I just read the old post about variable priorities to make sure, and it said that LOCAL overrode the system variable names.

Now, I can create a Home function with LOCAL A; inside the function and it compiles without a problem, but when I put LOCAL A; outside the function, it gives me a syntax error on compilation. I can do it with a new variable name, but it seems to have a problem with variable override of a variable already defined (like the system variable A in this case).

Whats the rule here? I can't remember if it did this before the Beta, but I am using the Beta release...

[Dirk.nl]

http://www.hpmuseum.org/forum/thread-215.html

[webmasterpdx]

That was the old post that I said I read.

I cannot put the line:

LOCAL A;

inside a program, and outside a function, as A is already defined in the System global variables.
That old post suggests that I should be able to do this, overriding the global name....again, I'm using the Beta. Has anyone without the Beta tried this to see if it used to work?

[cyrille de brébisson]

Hello,

LOCAL are local to a function (or a block within a function).
LOCAL have a limited lifetime (the execution time of the block in which they are. A function being a block).
LOCAL also have "stacking ability". If a block calls itself (or another block that declares a LOCAL with the same name, then 2 variables with the same name will (temporary) exist (with the last one being the only visible one).

They are not LOCAL to a program.
Variables declared outside of a funciton in a program are globals (because they last for as long as the program lasts, even if it does not execute. They are reset when the program is recompiled). But they will keep their values between 2 calls of functions in the program.
Program globals can be access from outside of the program using their fully qualified name (program_name.variable_name).
program global variables defined with an EXPORT keyword can be accessed from outside the program directly without a fully qualified name.

Cyrille

[webmasterpdx]

Cyrille, my understanding (and this is what the documentation says) is that a program global is EXPORT A; outside of a function.
So, you are saying that LOCAL A; outside of a function is, in fact, treated as a global, but isn't accessible by anything other than functions defined inside the same program file.
Thus, LOCAL A; outside a function, cannot coexist with an existing global, either inside another program file or a true global/system variable. This is why LOCAL A; gives a compile error.
Is my interpretation here correct?
Thx
-Donald

[Carlos295pz]

(11-16-2017 05:57 AM)cyrille de brébisson Wrote:  Global variables can be access from outside of the program using their fully qualified name (program_name.variable_name).
program global variables defined with an EXPORT ...

Oh! I thought that only the exported variables were accessible

[Carlos295pz]

It seems simple, the global variables (outside a function: LOCAL/EXPORT) can not have the same name as a variable, function or system command. It is also not possible to create functions under this same principle

[Tim Wessman]

(11-16-2017 06:04 AM)webmasterpdx Wrote:  Thus, LOCAL A; outside a function, cannot coexist with an existing global, either inside another program file or a true global/system variable. This is why LOCAL A; gives a compile error.
Is my interpretation here correct?

EXPORT makes the object appear as a "global" accessible anywhere directly by name. It will show up in menus/interfaces and behave like something "built in".

If you don't EXPORT it, the object can still be accessed directly by qualifying with program_name.var_name as such. It hasn't been completely hidden and it isn't able to override global objects. It just won't show up in interfaces or be accessible without full qualification EXCEPT to any functions defined in the same source file.

[cyrille de brébisson]

Hello,

(11-16-2017 06:04 AM)webmasterpdx Wrote:  Cyrille, my understanding (and this is what the documentation says) is that a program global is EXPORT A; outside of a function.

Originally (in the first versions of the 39GII+) , the syntax (for program globals) was:
LOCAL ?????; meant: global to the program and not directly visible to the outside world (unless fully qualified)
and EXPORT ?????; meant global to the program and directly visible to the outside world.

Then LOCAL became optional (which it was not originally), thus leaving only EXPORT. However, LOCAL was kept for backward compatibility.

Cyrille

[Han]

(11-16-2017 06:04 AM)webmasterpdx Wrote:  Cyrille, my understanding (and this is what the documentation says) is that a program global is EXPORT A; outside of a function.
So, you are saying that LOCAL A; outside of a function is, in fact, treated as a global, but isn't accessible by anything other than functions defined inside the same program file.
Thus, LOCAL A; outside a function, cannot coexist with an existing global, either inside another program file or a true global/system variable. This is why LOCAL A; gives a compile error.
Is my interpretation here correct?
Thx
-Donald

To answer your question directly: YES. In the specific case when you try to declare a LOCAL variable OUTSIDE of any function AND using an existing system variable name, you will get a compile error.

Now, if you had a different program file (say, PROG1) that declared EXPORT MYVAR1; and within yet another program file (named PROG2) you declared EXPORT MYVAR1, you will NOT get a compile error. The program will (I have not tested this) use the correct MYVAR1 since at compile time it creates reference links to variables and functions. However, if you try to access MYVAR1 from outside the program (i.e. via command line to perhaps modify the content of MYVAR1), then the MYVAR1 that was last compiled is what gets referenced. In order to reference the correct MYVAR1, you need to qualify them with the program file name: PROG1.MYVAR1 or PROG2.MYVAR2

The ambiguous behavior only occurs when you use the (ambiguous) shorthand names to reference the variables.