Post Reply 
Little explorations with HP calculators (no Prime)
03-10-2018, 05:14 PM (This post was last modified: 03-10-2018 05:33 PM by DavidM.)
Post: #264
RE: Little explorations with HP calculators (no Prime)
(03-10-2018 11:36 AM)pier4r Wrote:  On the 50g if one provides no argument one gets the standard error "too few arguments". Is it possible to catch this error?

Using an IFERR structure to encapsulate your code would work, and you can even use ERRN (or ERRM, but not as efficiently) to determine what the actual error was that occurred. That would allow you, for example, to branch in different directions depending on exactly what error condition was triggered. Error trapping is a nice feature on the RPL machines that can improve the usefulness of programs when applied correctly.

However...

You could also use the approach used by most built-in commands, which is to check both an argument count as well as the types of those arguments at the beginning before proceeding. The basic premise of this model is that if you know the arguments are good at the beginning, the rest of the program flow should guarantee that intermediate results will always match what is needed as the program proceeds. This is exactly what almost every UserRPL command does internally -- arguments are checked at the beginning, then operations are performed knowing that all intermediate results should be in place as expected until the command completes. Once control is passed back to the whim of the user, all bets are off, so the next UserRPL command has to perform all the checks again since it can't assume that everything is where it needs to be.

The fact that most all UserRPL commands do this is both good and bad. Good in that the commands are robust, but bad in that all of this checking going on at each and every step slows things down. This is actually one of the biggest reasons that SysRPL programs generally run faster than UserRPL: they only check the arguments at the beginning, and the rest of the commands simply execute with no safety checks on the arguments given to them.

The DEPTH and TYPE commands can be used to check argument counts and types, but you would have to customize your code around them. It's also possible to generalize this concept by providing your own sub-program that could be more generic. Something like the following could be useful:
Code:
ARGCHK
\<<
  0. ADD DUP SIZE \-> at ac
  \<<
    IFERR
      ac \->LIST
    THEN
      DROP ERRN DOERR
    ELSE
      DUP 1 \<< TYPE \>> DOSUBS 0. ADD
      SWAP LIST\-> 1 + ROLL
      IF at SAME NOT THEN #202h DOERR END
    END
  \>>
\>>

ARGCHK takes one argument: a list of types as defined by the TYPE command. So some examples of how you might call it are as follows:
Code:
@ check for two strings on stack
{ 2 2 } ARGCHK

@ check for a string, a list, and a binary integer
{ 2 5 10 } ARGCHK

@ check for an approximate number
{ 0 } ARGCHK

Additional objects above the expected ones are ignored, but anything else (including -nothing-) in the indicated stack levels will raise an appropriate error.

One of the issues you run into with this type of argument checking is that exact integers and approximate numbers have distinctly different types (28 and 0). So your program may work just fine with either of them, but you would have to adjust how you check for them to make sure that needless errors aren't generated. This could be done in a variety of ways, including creating your own "type number" to represent both numeric types and replacing the subroutine being passed to DOSUBS above to create that type when appropriate. Similar issues arise if you start to consider units and tagged objects as well. These are all things to keep in mind, and perhaps one of the reasons that not many UserRPL programs are written with these kind of checks. Smile
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: Little explorations with HP calculators (no Prime) - DavidM - 03-10-2018 05:14 PM



User(s) browsing this thread: 3 Guest(s)