|Re: WP 34S programming question - bug!|
Message #27 Posted by Paul Dale on 10 Apr 2012, 6:39 p.m.,
in response to message #26 by fhub
The biggest problem I see here is there is no visual indication that the return stack is empty or not. Thus, a pair of devices that appear to be in exactly the same state will behave differently based on this invisible extra information. I believe this fails the "lets limit user surprises" test.
Are you using a bit or a byte for this 'toplevel'?
We don't store even a single bit to indicate the top of the return stack. We know where that is and act accordingly based on the value in the stack pointer.
This 'waiting' state should be set whenever a STOP or PROMPT is executed in a program (maybe there's even any free announciator in the display for it?), and it should be reset when the program continues (with R/S).
What happens if the executed subroutine itself executes STOP or PROMPT? Seems like one bit of state isn't sufficient. One per subroutine level is more realistic. We might be able to squeeze this into the return addresses but I'm not positive.
What commands would clear this setting? I don't believe that just R/S should -- keyboard RTN? Clear program? LOAD? The user will want to execute several subroutines after a STOP, so things like RTN and END can't na´vely clear it.
How to I escape this nest of recursive fun if I want to give up running the current program or switch to a separate application? e.g. I want to go use the TVM code during a program run and then continue the program execution....how?
How do we make it obvious to the user that XEQ will finish in an application versus returning back to where they are?
Once these questions are properly addressed, we can begin considering how to implement this suggestion. Until they are consider, there is no point looking hard at the implementation details. In other words, we need to transform your idea into a proper proposal.
An extra complication would be that many commands are user programs now and you'll have to be able to execute them without impacting this setting. I don't think this will be a major issue to support, but it will need consideration as well.