Recursion in RPL using local variables Message #8 Posted by Tom Barber on 28 Sept 2006, 3:52 p.m., in response to message #7 by GE
Quote: You [Kiyoshi] are right about the locality of variables - but it was fixed with the '<-' trick, was badly needed, and should have been here on day one.
Even though I don’t presume to understand everything that GE writes, I believe that I understand this adequately to be confident that I don’t agree. The mechanism of compiled variables is demonstrably superfluous. While I may not have demonstrated the general truth of that, I certainly demonstrated conclusively, in the post that initiated this thread, that the problem at hand, i.e., the problem of how to use a local variable to implement recursion, is readily solvable using only the ordinary mechanisms of local variables. Those ordinary mechanisms solve the problem entirely, provided only that you have no objection to placing the recursive program within the declarative scope of the name that you wish to assign to that program. I have no problem whatsoever with doing that, and so far as I can tell when looking at it from the procedural perspective, it works perfectly.
Quote: Also, I don't see any reason for local variables not to propagate down to called subroutines. If the same local variable were defined again, it would hide previous same named ones.
The problem with that is that local scope has precedence over global scope. If local variable scope were to automatically extend into called subroutines, there would be no straightforward way to know, upon inspecting the subroutine, whether a name within that subroutine, which is not locally scoped within the subroutine, will bind to a variable declared locally in the calling routine, or will default to global scope. Manifestly, this is the reason for the additional requirement that a variable that is to be treated as a compiled variable must be named specially, starting with “<-“. You cannot create an actual global variable using that. The naming rule requires you to explicitly differentiate, particularly within programs that will be called from other programs, the names for which you desire this behavior, from the names for which you desire the behavior of defaulting to global scope. If you do not ever want any of the variables in any of the programs that will be called from other programs to default to global scope, then even though it would be cumbersome, you could apply the special naming rule for all your variables in all your programs. Personally, I would not desire that, because from my perspective, all this actually does is to give you an alternative to using the stack to pass parameters and receive results in the manner that is endemic to a stack-based language.
Quote: My biggest complaint regarding RPL could be the very bad job done by the editor, which very effectively obfuscates the code when you press [Enter] - and we know there is a hard, theoretical reason for that.
I agree with this. I was highly annoyed at this behavior, but eventually realized that the integrated behavior of the editors and OBJ->, yields a consistent system of sorts. Once you commit to the practice of maintaining programs as strings, you discover that the true obstacle is not with the behavior of the editor, but is rather that when the program that is encapsulated within a string is not syntactically correct, OBJ-> does not identify the error to you. When that happens, you find yourself in a bit of a predicament, but even then, the medicine that you must swallow, isn’t so bad.
Here are some excerpts from my book, specifically from the section that is devoted to using strings to encapsulate programs:
“There are significant advantages to writing and maintaining your programs as strings, i.e., using strings to encapsulate your programs. Each time that the editor exits, the content is evaluated in the familiar manner of the command line interpreter. As programs are pushed onto the stack, subtle changes occur. The voluntary white space characters that have no effect in the program, which includes line breaks, are stripped. Moreover, even though the editor permits you to put comments in your program, it strips them out of the program as the program exits the editor. (Comments start with the ‘@’ character and continue until the next ‘@’ or line break.) If you encapsulate your programs within strings, your indentation and comments will be preserved.”
…
“When OBJ-> is applied to a string, the command line interpreter receives the proper content of the string, i.e., the string as it appears within the type-aware editor. A syntactically correct program will be pushed onto the stack. If the proper content of the string is not a syntactically correct program, OBJ-> will put the string back on the stack and will report an error. When this occurs, your best option is to do the conversion manually, using the editor that is not type-aware. You can use the global text replacement capability to remove the escape characters, and then manually remove the double-quote characters that encapsulate the program. The error will then be identified as you attempt to leave the editor, but if you proceed to make the corrections then and there, the string version stored in the variable will not benefit from the correction.”
Edited: 28 Sept 2006, 4:28 p.m.
|