Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!rutgers!orstcs!jacobs.CS.ORST.EDU!louxj From: louxj@jacobs.CS.ORST.EDU (John W. Loux) Newsgroups: comp.sys.handhelds Subject: Re: Poor documentation ? Message-ID: <20599@orstcs.CS.ORST.EDU> Date: 28 Sep 90 17:21:57 GMT References: Sender: usenet@orstcs.CS.ORST.EDU Organization: Solve and Integrate Corp. - Corvallis Lines: 40 oluf@IFI.UIO.NO (Asle Olufsen) writes: !As a test I created the following program: ! ! << -> X << HALT >> >> ! !I put 1 on the stack and starts the program. The info-area says HALT !and X ENTER gives 1 and 'X' EVAL does the same. When I do CONT this !effect dissapears. So far so god. ! !Then I put 'X' and 2 on the stack and starts the program. HALT comes !up and 'X' is on the stack. I do EVAL and get 'X'. Nothing happens. I !may put 'X' on the stack now and do EVAL and gets 2, but a 'X' that is !on the stack before I starts the program does not get evaluated. OK, !so HP uses statical variabel bindings not dynamic. This could be !useful. ! !Then I do CONT and clears the stack. And I put 3 on the stack and starts !the program. HALT comes up and I put 'X' on the stack. Then I do CONT !which removes the HALT but leaves the 'X' on the stack. Then I do EVAL !end gets Eval error: Undefined Local Name. Rats. HP does not use !stacical variable binding either. Or do they ? It is perhaps better !to say that they use a kind of stacical variable binding which can't !be used for something useful. Annoying. ! !Oluf Email: oluf@ifi.uio.no I believe that I sent a response to you via email (or was I dreaming?), but it's worth replying to the net as well. The 'X' in consideration is actually two different objects. The 'X' created outside the scope of the halted program is a GLOBAL name bound to 0 or 1 objects in the global environment. The 'X' created within the scope of the halted program was a LOCAL name bound to 0 or 1 objects within that particular local environment. If I understand the terminology rightly, the 48 uses static binding, but in the case of the local name left on the stack, its environment was dynamic and deallocated before the name was evaluated (dereferenced). Hope I've helped.