Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!ukma!rsg1.er.usgs.gov!rsg1.er.usgs.gov!stevev From: stevev@greylady.uoregon.edu (Steve VanDevender) Newsgroups: comp.sys.handhelds Subject: Re: HP-48 programming problem Message-ID: Date: 10 Apr 91 05:07:29 GMT References: <1991Apr9.021224.27070@usenet.ins.cwru.edu> <668@uqcspe.cs.uq.oz.au> Sender: news@rsg1.er.usgs.gov Organization: University of Oregon Chemistry Stores Lines: 52 In-Reply-To: grue@cs.uq.oz.au's message of 9 Apr 91 09: 08:32 GMT Unfortunately, the technique you suggest won't do what I thought the original poster really wanted, which was to be able to make a subroutine that would apply INCR to an arbitrary variable. Another poster didn't notice that INCR was being called and thought that the original poster wanted to pass the value of a local name 'a' to the subroutine, not the name itself. You can pass local names into a subroutine to do operations that need a local name and not just its contents, but you cannot make the subroutine completely general because passing a local name which is also used in the subroutine will cause the subroutine to operate on its own local variable, not on the one in the caller. There is no way to pass a reference pointer to a variable so that a subroutine can operate on any variable in any scope in standard RPL. RPL has different scope rules for global names and local names, which I find very interesting. Global names are statically scoped based on the current PATH. Global name references are resolved by searching the current directory, then the parent of the current, then its parent, on up to HOME. The run-time nesting of functions has no effect on the resolution of global name references. Local names are dynamically scoped based on the run-time nesting of functions. A local name reference is resolved by searching the bindings of the current function, then in the function that called it, then in the function that called that, and so on. If a function passes a local name into another function, and the called function doesn't use the same local name, then references to that local name get its value in the calling function. A function that refers to a local name without first creating it, like the one you created with \<< \-> a \<< \<< 'a' INCR \>> 'INC' STO \>> \>> will end up being completely dependent on run-time function nesting to determine its effect. I don't want to say that this kind of dynamic scoping is bad, but it can produce some very counterintuitive behavior and the kinds of problems that the original poster reported. Generally nobody uses dynamic scoping any more in programming languages. I think that knowing it is used in RPL is very important because of the subtle effects it can have. -- Steve VanDevender stevev@greylady.uoregon.edu "Bipedalism--an unrecognized disease affecting over 99% of the population. Symptoms include lack of traffic sense, slow rate of travel, and the classic, easily recognized behavior known as walking."