[34S] Proposal for Entry RPN mode with dynamic stack

[Bit]

(02-19-2015 01:05 AM)BarryMead Wrote:  Stack operations are deceptively SIMPLE LOOKING. They APPEAR to be easy, but are always much more complex under the surface. Paul Dale mentioned that stack operations were "Pervasive" and that you would need to look at code affected by at least three stack related variables to correctly alter program behavior. I am just saying that, from my experience, more things will break than you can possibly imagine.

Implementing 'Entry RPN' (without the dynamic stack) may not to be as difficult as one might think, although very thorough testing would be needed as usual. I've just had a quick look at the code and there aren't very many places that deal with stack lifts, and XROM code could easily be exempted. Provided, of course, that the precise specification, once we have one, doesn't introduce some unexpected complexity. ENTER is simple but what should CLx do? Clear the command line if present and then DROP? Something else? What about Σ±?

I'd expect trouble with library and user programs. If they change the RPN mode and get paused or interrupted, it'd be a major source of confusion for the user if the ENTER key suddenly works differently, especially as it may not be noticed right away. If the mode change only affects the program (e.g. it's stored as a local flag), then what should happen if you single step a program? I can't think of a good solution other than rewriting all library routines so they work correctly in both RPN modes and warn users that their programs will break unless they pay attention to this.

Ultimately I think creating a well thought-out specification that provides a consistently good user experience and covers every detail might be more work than the programming.