PPL programming question; local variables

[CR Haeger]

Hello,

Thanks to HAN for preparing this excellent guide: http://www.hpmuseum.org/forum/thread-216.html

I'm new at PPL programming and made it through all but the last program. The following code runs fine and is based on Part IV #2 code Han provided.

PHP Code:

// program declarations 
THIRDANG(); 
ANG(); 

// Local variables
LOCAL angle1, angle2; 

// THIRDANG(a,b) // Takes two angles a and b (in radians) of a triangle and // returns the third angle (in degrees) 
EXPORT THIRDANG(a,b) //<-- ** Can I change this to THIRDANG(angle1, angle2)?

BEGIN   
  angle1:=a;   // <-- ** Can I delete this?
  angle2:=b;   // <-- ** Can I delete this?
  IF HAngle==0 THEN
    ANG();
  END;   
  RETURN(180-angle1-angle2); 
END; 

// ANG() // Takes an angle a (in radians) and returns the same angle in degrees 
ANG() 

BEGIN   
  angle1:=angle1/PI*180;   
  angle2:=angle2/PI*180; 
END; 


But, if I try to shorten the code to the following, it appears that the local variables are not passed to the ANG() subroutine when it is called. Why not?

PHP Code:

// program declarations 
THIRDANG(); 
ANG(); 

// Local variables
LOCAL angle1, angle2; 

// THIRDANG(a,b) // Takes two angles a and b (in radians) of a triangle and // returns the third angle (in degrees) 
EXPORT THIRDANG(angle1, angle2) //<--  edited
BEGIN   
     // angle1:=a; <-- Deleted
     // angle2:=b; <-- Deleted
  IF HAngle==0 THEN
    ANG();
  END;   
  RETURN(180-angle1-angle2); 
END; 

// ANG() // Takes an angle a (in radians) and returns the same angle in degrees 
ANG() 

BEGIN   
  angle1:=angle1/PI*180;   
  angle2:=angle2/PI*180; 
END; 


Best,
Carl

** Updated second code...

[eried]

The second 'shortened' code has syntax errors.

[CR Haeger]

(02-13-2014 12:49 AM)eried Wrote:  The second 'shortened' code has syntax errors.

sorry - updated shortened code. Runs without syntax errors now, just not correctly

[eried]

Code:

EXPORT THIRDANG(angle1, angle2) //<--  edited

The function re-declares the angle1 and angle2. I am not sure if you can reference the outer/inner ones with some notation. So, you can't delete the lines from the first script. In other languages you can do something like this, but I am not sure if there is something similar here:

Code:

EXPORT THIRDANG(angle1, angle2) //<--  edited
*something*.angle1 = *something2*.angle1;
...

Using ANG() as function is totally pointless. In general, every function call uses resources, so for something that only saves you 1 line, isn't necessary. Also using globals is kinda bad practice.

[CR Haeger]

Thank you. Yes I wondered about the effect of declaring the local variables twice.

This is just practice code based on a tutorial provided by Han.

[eried]

I am not sure if Han recommends re-declaring local vars outside and as parameters with the same name. You can do what you tried to do using another names for the parameter.

Anyway in general terms, you should avoid global vars, and unnecessary function calls (if the function is a couple lines and it is called once, then it shouldn't be a function, but also 'very lengthy functions' aren't good anyway).

[CR Haeger]

(02-13-2014 07:01 AM)eried Wrote:  I am not sure if Han recommends re-declaring local vars outside and as parameters with the same name. You can do what you tried to do using another names for the parameter.

Anyway in general terms, you should avoid global vars, and unnecessary function calls (if the function is a couple lines and it is called once, then it shouldn't be a function, but also 'very lengthy functions' aren't good anyway).

Thank you. Yes, I was wondering if re-declaring local vars as parameters is what prevents them from being passed to the subroutine ANG(). I was hoping to not have to have (a,b) as separate local variables but maybe I have to in this case.

[Han]

(02-13-2014 11:47 AM)CR Haeger Wrote:  

(02-13-2014 07:01 AM)eried Wrote:  I am not sure if Han recommends re-declaring local vars outside and as parameters with the same name. You can do what you tried to do using another names for the parameter.

Anyway in general terms, you should avoid global vars, and unnecessary function calls (if the function is a couple lines and it is called once, then it shouldn't be a function, but also 'very lengthy functions' aren't good anyway).

Thank you. Yes, I was wondering if re-declaring local vars as parameters is what prevents them from being passed to the subroutine ANG(). I was hoping to not have to have (a,b) as separate local variables but maybe I have to in this case.

Those are all good recommendations. I just wanted to clarify a few points. The only global variable is the routine FINDANG() -- i.e. only exported variables are considered global. Defining local variables outside a procedural block doesn't make them global (in the same sense as the built-in variables A through Z) but simply gives them "file scope" from the point of declaration to the end to the file. They are similar to variables in C/C++ declared outside of functions.

The point of ANG() was to merely demonstrate the use of local variables declared outside of a procedural block. There are only a few instances in which something like ANG() would be used. For example, the MAKEMAT() command has three parameters: an expression in terms of I and J, the number of rows, and the number of columns. The expression can be a simple IF THEN END statement. However, the structure of the language does not allow such a block as a parameter so that you must use a separate function for your expression.

[CR Haeger]

Han, thank you again for the reply and the informative articles. They are really helpful for me to start PPL programming.

From my original post, I was really asking if replacing

THIRDANG(a,b) with THIRDANG(angle1, angle2) would prevent angle1 and angle2 from being passed to the ANG() subroutine.

I thought declaring LOCAL angle1, angle2; would allow this, but maybe not.

Best,
Carl

[Han]

(02-13-2014 02:53 PM)CR Haeger Wrote:  Han, thank you again for the reply and the informative articles. They are really helpful for me to start PPL programming.

From my original post, I was really asking if replacing

THIRDANG(a,b) with THIRDANG(angle1, angle2) would prevent angle1 and angle2 from being passed to the ANG() subroutine.

I thought declaring LOCAL angle1, angle2; would allow this, but maybe not.

Best,
Carl

In terms of priority, the angle1 and angle2 variables within THIRDANG() have higher priority over angle1 and angle2 declared toward the top. Unlike app variables, which can be fully named via Appname.variablename, there is no mechanism to reference the angle1 and angle2 declared outside of a procedural block if you also use local variables of the same name within said procedural block. In general, a local variable declared inside a procedural block will have highest priority.

You can confirm this with (updated):

Code:


SUBPRG();
LOCAL var1=1, var2=2;

EXPORT MYPROG(var1,var2)
BEGIN
  PRINT(var1 + " " + var2);
  WAIT(-1);
  SUBPRG();
END;

SUBPRG()
BEGIN
  PRINT(var1 + " " + var2);
  FREEZE;
END;

If you run MYPROG(-1,-2) then you will see that MYPROG prints -1,-2 even though var1 and var2 were initialized to 1 and 2 respectively. Moreover, the var1 and var2 values declared outside of MYPROG are still retained (they are distinct from those declared within the definition of MYPROG. Hence SUBPRG prints 1, 2.

[rprosperi]

Actually, I don't think that would run as-is, since SUBPROG() was not declared above the invoking line. Simply adding SUBPROG(); above the EXPORT line should resolve it. Right?

I'm gonna gamble and leave this comment while I test it.

Oh, and I learned this from you Han, I'd like to add my thanks to you as well for nice intro lessons, plus all the other insigthful tips and replies you make. A real help in learning Prime.

[eried]

(02-13-2014 05:36 PM)rprosperi Wrote:  Actually, I don't think that would run as-is, since SUBPROG() was not declared above the invoking line. Simply adding SUBPROG(); above the EXPORT line should resolve it. Right?

Or moving the whole function up

[Han]

(02-13-2014 06:31 PM)eried Wrote:  

(02-13-2014 05:36 PM)rprosperi Wrote:  Actually, I don't think that would run as-is, since SUBPROG() was not declared above the invoking line. Simply adding SUBPROG(); above the EXPORT line should resolve it. Right?

Or moving the whole function up

Good catch! My copy and paste left off the declaration at the top. I'll edit it now and make the necessary fix.