Global vs Local behaviour

[DrD]

The use of a command line entry "global" variable would make the contents available for other activities when a program concludes. As implemented, there is a problem with this reasoning, because a program that passes a value in via the command line, automatically makes that input variable "local" in context. Here is an example:

Code:


EXPORT stg:="DRD";
EXPORT str()
BEGIN      
  return stg;
END;

The global variable retains its programmed contents, remaining available at the end of run time. Suppose its desired to pass parameters via the command line:

Code:


EXPORT stg;
EXPORT str(stg)
BEGIN      
  return stg;
END;

In this example, the global variable, stg, gets displaced by a local (same name) variable during input. Any programmatic effect on stg vanishes once the program terminates. If the "command line input" were to initially check for the 'global' existence of its variable, I think it would enhance the process of parameter passing via the command line.

What do other users think about this?

[kharpster]

I am fairly new to the HP Prime, but I think the correct way to declare a global variable so that it behaves as you expect is like this:

Code:


stg;
EXPORT str(stg)
BEGIN      
  return stg;
END;

If you change the value of the global variable used within the program the initial value will of course be lost (replaced):

Code:


stg;
EXPORT str(stg)
BEGIN      
  stg := 32;
  return stg;
END;

From my testing it would seem that the first place a variable is defined is where it's scope is assigned. Therefore if you define the variable as global even if you define the variable again inside of the BEGIN/END it remains a global and not a local variable, which could be confusing. Having the editor check to see if a variable has already been defined would be nice, but a little design effort can also avoid these types of problems.

Code:


stg;
EXPORT str(stg)
BEGIN 
  stg;     
  return stg;
END;

[DrD]

Please see the "EXPORT" function description in the help file, regarding declaration of globals.

If the global's contents are modified within the program, i.e, then the global's modified contents should be available for other usage once the program has terminated. In the second example (command line input) the global is ignored, since a (new) local variable received the activity, and vanished on exit, with the original global retaining its previous value.

I suppose either approach is valid, but there are instances where it would be nice to directly effect the global with the command line input. I was thinking it would be a useful idea to have the command line input check for the existence of the variable in use (thus it would have been a global), before creating the new local variable.

I'm not sure others would agree, and was wondering what the sentiment would be, if any.

[kharpster]

My apologies DrD, I was mistakenly addressing global variables used within a project. Using the EXPORT command when declaring a variable exposes the variable so that as you have stated, it can be used as input for another function or program after your program has completed execution. Whereas my coding example is how global variables are defined for use within projects that contain multiple subprograms. Variables declared globally as I have shown are available for use within every subprogram in your project. You can refer to a prior post of mine http://www.hpmuseum.org/forum/thread-3596.html in which I have a working project that demonstrates the use of global variables in a project that contains multiple subprograms (procedures).

Back to the EXPORT variable issue. I would personally never use the "EXPORT" variable in my code until right before I performed the Return operation, where I would populate it accordingly.

Like this:

Code:


EXPORT stg:= "DRD";

EXPORT str(stx)
BEGIN   
  stg := stx;          
  return stg;
END;

[DrD]

I intentionally used the return example to keep it as brief as possible, yet demo the effects. The circumstances came up in another project involving string concatenation and formatting needed for the print terminal. There's almost always work arounds, but passing in parameters using global variables can be quite useful, especially so when debugging outside of programs.

[kharpster]

For my own piece of mind I wanted to verify how global user variables are passed into a program on the Prime, here is what I did, and what I found:

Here is the test program; please note that the input variable name (stx) is different from the global user variable name passed in (stg) on the command line below.

Code:


EXPORT stg;
EXPORT str(stx)
BEGIN   
  stg := stx;  
  return stg;
END;

The following is what I entered on the command line:

Code:


"test" (sto) stg                   “test”
stg                                   “test”    
str(stg)                            “test”
stg                                  “test”

I then changed the program to modify the value of the global user variable:

Code:


EXPORT stg;
EXPORT str(stx)
BEGIN   
  stg := stx * 10;  
  return stg;
END;

And entered the following on the command line:

Code:


10 (sto) stg                   10
stg                                   10    
str(stg)                            100
stg                                  100

As you can see the original value of the global user variable stg (10) is passed into the program via the input variable stx in the program. The value of the global user variable stg is then modified by the program and returned with the new value by the RETURN statement.

Summary:

Input variables are passed by value and not by reference.

You must use a different name in your program for the local input parameter variable than that of your global user variable used for RETURN.

You can pass in the same global user variable as that declared in your program, and then modify and return the new value in the same global user variable name.

[cyrille de brébisson]

Hello,

Note that in your function you should be able to do:
EXPORT stg;
EXPORT str(stg)
BEGIN
stg := stg+My_Program_Name.stg;
return stg;
END;

No, the parameter list will not check for globally defined variables and err on it.
That is, in some ways, the whole point of local variables, to 'override' global settings and allow you to create a function that is agnostic of what is happening in the rest of the world.

If it WAS to test for global variables, then the function/program might work on one machine and not on another as the global variable could exist on one calculator and not another, creating problems.

Cyrille

[DrD]

I think I may have found something I hadn't noticed before, which may explain my concern being debated in this discussion. Apparently, if a variable is created via the command line, (for example and notice Type: string):

[HOME]stg:="Stuff";

and then a program using that variable name "EXPORT str(stg)" just gets COMPILED, it destroys the original value, in what I was thinking was a global variable, (compile, but don't run this yet):

Code:


EXPORT stg;
EXPORT str(stg)  
BEGIN      
  return stg;
END;

Notice that the value of the (global?) command line variable stg gets destroyed:

[HOME]stg; ===> 0.00 (Type: real)

It seems like the compiler over-writes the (pre-existing) initial command line version. Thoughts, bug (y/n)?

-Dale-

[Didier Lachieze]

(05-04-2015 11:34 AM)DrD Wrote:  I think I may have found something I hadn't noticed before, which may explain my concern being debated in this discussion. Apparently, if a variable is created via the command line, (for example and notice Type: string):

[HOME]stg:="Stuff";

Now you have created a User Variable as you can see with the Vars key:

(05-04-2015 11:34 AM)DrD Wrote:  and then a program using that variable name "EXPORT str(stg)" just gets COMPILED, it destroys the original value, in what I was thinking was a global variable, (compile, but don't run this yet):

Code:


EXPORT stg;
EXPORT str(stg)  
BEGIN      
  return stg;
END;

Now you have created another stg global variable in the str context:

(05-04-2015 11:34 AM)DrD Wrote:  Notice that the value of the (global?) command line variable stg gets destroyed:

[HOME]stg; ===> 0.00 (Type: real)

It seems like the compiler over-writes the (pre-existing) initial command line version. Thoughts, bug (y/n)?

-Dale-

The latest referenced "stg" variable is the one accessed, but the original one has not been destroyed as you can retrieve it's content if you delete the str program.
If you have two global variables with the same name (stg) Exported from two programs (pgm1, pgm2) you can access them as pgm1.stg and pgm2.stg, what I don't know is which qualifier you should use to access the stg User Variable.

[DrD]

Yes, good catch... I didn't see that. That will help in sorting things out the next time this kind of thing pops up for me.

EDIT:

I've learned that there are three activities that impact the contents of a global variable:

1. Command line, creates the User Variable: stg:="Stuff"
2. Compile time, re-creates the str.stg which is the same as User.stg (stg and str.stg both become 0.00 reals)
3. Run time, creates a local variable whose contents vanish after program ends. Contents from the (refreshed) command line remain intact:

stg="Stuff" ==> run program, input "Junk" ==> returns "Junk" ==> stg="Stuff" and str.stg="Stuff" (No difference between User var and qualified var.)

So a user would need to remember that a global value is only good if established AFTER a program has been compiled, or in other words, a global value will be destroyed if its further use in a program will undergo compiling.

This is the way it works in my emulator instance, anyway.

[leprechaun]

Quote:The latest referenced "stg" variable is the one accessed, but the original one has not been destroyed as you can retrieve it's content if you delete the str program.
If you have two global variables with the same name (stg) Exported from two programs (pgm1, pgm2) you can access them as pgm1.stg and pgm2.stg, what I don't know is which qualifier you should use to access the stg User Variable.

Is that really better than having directories?