Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!coplex!disk!corpane!herman
From: herman@corpane.uucp (Harry Herman)
Newsgroups: comp.sys.handhelds
Subject: Re: HP-48 programming problem
Message-ID: <1991Apr10.034606.3557@corpane.uucp>
Date: 10 Apr 91 03:46:06 GMT
References: <1991Apr9.021224.27070@usenet.ins.cwru.edu>
Organization: Corpane Industries Inc.
Lines: 59

In <1991Apr9.021224.27070@usenet.ins.cwru.edu> rkb@po.CWRU.Edu (Robert K. Brunner) writes:


>I had a problem debugging a program today, and I was wondering if anyone
>had encountered the same problem before.  The problem isn't a bug, but
>it is annoying behavior.

>Suppose you have the following variables:

>P1: \<< \-> a \<< 'a' INC \>> \>>
>INC: \<< \-> a \<< a INCR DROP \>> \>>

>Executing 5 P1 gives INCR Error: Bad Argument Type.
>If you change the local variable in either of the programs to something 
>different, you get 6, as you would expect.  Apparently, INC thinks
>that the 'a' on the stack refers to the innermost local variable,
>rather than the one belonging to P1.  If this behavior is documented
>in the manuals, I haven't seen it.  

>Robert

If you re-wrote the procedure as:
	\<< \-> a \<< 'a'
		\<< \-> a \<< a INCR DROP \>> \>>
	\>> \>>
then the section on local variables in Volume II of the Owner's Manual
states that local variables in inner levels take precedence over
variables defined in outer levels that have the same name.

From stepping through your original programs with SST\/, I found that
when INCR was finally reached inside INC, the value on level 1 was:
	'a'
I suspect that this is stored as an alphabetic name to be resolved
to an address at run-time, it is not stored as the address of a in the
routine P1.  So, any attempt to look up the value of a inside INC always
returns 'a', it never returns the 5 passed to P1 at the beginning.
I even varified this by putting 'a' on the stack while in the debugger
at the point that the "Bad Argument Type" message appeared, and repeatedly
pressing RCL, trying to see if it would work its way back to the original
value of 5, and it never did.  It always left 'a' on the stack.

So, the only solution is to pick a unique local variable name for the
called procedure that is not used by any of the routines that call it.
For example, if the local variable in INC was lksdjf instead of a, then
the procedure would work, and the odds of you ever passing a variable
called lksdjf to it would be every slim.

When I was progamming in a version of BASIC that supported long names,
but did not support multi-line functions, I named all the "local variables"
(no such thing in BASIC, unless multi-line functions are supported) after
the routine name.  For example, I would have called the variabl a inside
INC, INC_a, and the variable a inside P1, P1_a.  That way I could still
think of myself using a as the variable name, but be guaranteed that
the names were unique.

				Harry Herman
				herman@corpane
					or
				...uunet!ukma!corpane!herman