(Comp.sys.handhelds)
Item: 2319 by billw at hpcvra.cv.hp.com.
Author: [William C Wickes]
  Subj: HP48 New IFERR II
  Date: Tue Mar 05 1991 17:52

                      The Return of New IFERR

The library listed at the end of this note is a new version of the
IFERR library previously posted, which corrects the problem associated
with command line execution.  You should delete version A of this library
if you still have it.  Please notify me if any problems arise with
version B.

[Note!  The "A" version Bill refers to can be found on EduCALC Goodies Disk
#2.  Delete it!  The IFERR.LIB file on this disk obsoletes it.  -jkh-]

Several HP 48 programmers have expressed a concern that the current error
trapping mechanism via IFERR is vulnerable to repeated ATTN key presses, which
can prevent a program from cleaning up when it is interrupted by the user.
This problem arises because IFERR and all other branching constructs built into
the HP 48 check to see if ATTN key has been pressed so that users cannot
(easily) lock themselves into an uninterruptible loop.  

The object listed below in ASC-> form is an HP 48 library titled "IF ERROR ver.
B", that provides an alternate version of IFERR/THEN which can be uniformly
substituted for the built-in versions.  The difference between this version and
that built into the HP 48 is in the handling of ATTN.  The ATTN key check is
disabled for the THEN clause of the version provided in this library, allowing
for an "unbreakable" recursive error recovery.

Version B includes an additional modification.  The built-in IFERR...THEN
automatically clears the key buffer, and cancels pending execution of the
object associated with the key that started command line execution.  In version
B, the replacement IFERR does not clear keys.  A new command FLUSHKEYS is
provided, so that the programmer can control pending key execution.  FLUSHKEYS
takes no arguments, and clears the key buffer and the pending key object.

An example of the use of the new IFERR is given in the program below.  In the
"main" program, a loop display a counter running from 1 to 1000.  If you press
ATTN while it is running, the error trap starts another counting loop, this
time from 1 to 50, to show you that an error termination sequence of some
length is running.  If you interrupt it, it just restarts itself.

In the first line, a temporary variable, et, is allocated.  This variable will
hold the error termination procedure after it is created in the next part of
the program.  The error termination procedure is simply a cleanup procedure
protected by an IFERR which branches back to itself recursively if an error
occurs in its execution.  It is created in a list to avoid the inclusion of the
opening and closing program quotes, which themselves have attention key checks.
The remainder of the program is protected by IFERR...THEN et EVAL END.  

Notes:
* You must access the error termination procedure via a temporary variable
because global variable execution itself contains an attention key check.

* If your cleanup procedure has an unavoidable error, the only way to stop
infinite execution is by [ON]-[C].

* The library (which has ID 1793) is auto-attaching: to use it, all you need to
do is store it in a port (port 0, say) by putting it on the stack and executing
:0:1793 STO, and then turning the HP 48 off and on.

* To convert old programs containing IFERR to the new version, you need only to
EDIT (VISIT), then ENTER when the library is attached.  Downloading a program
in ASCII form via kermit will also automatically use the new IFERR.

Bill Wickes
HP Corvallis

Sample error trap program mentioned above [called TRAP on this disk. -jkh-]:
----------------- cut here ----------------------------------------------
%%HP: T(3)A(R)F(.);
\<< 0 \-> et
  \<< { IFERR 1 50
             FOR j
              "YOUR CLEANUP PROC." 1 DISP
              "#" j \->STR + " HERE" + 2 DISP
             NEXT
        THEN et EVAL
        ELSE DONE
        END } OBJ\-> DROP
    'et' STO
    IFERR 1 1000
      FOR j
        "YOUR MAIN PROC." 1 DISP
        "#" j \->STR " NOW" + + 2 DISP
      NEXT
    THEN et EVAL
    END
  \>>
\>>
----------------- cut here ----------------------------------------------

(Comp.sys.handhelds)
Item: 2405 by _macrokid at hpcvbbs.UUCP
Author: [Kevin Vashi]
  Subj: IFERR Problem.
  Date: Tue Mar 12 1991
----------
  Resp: 1 of 1 by billw at hpcvra.cv.hp.com.
Author: [William C Wickes]
  Date: Wed Mar 13 1991 17:52

Kevin Vashi writes:

> If you have created programs that have the IFERR..THEN..END structure
> after the IFERR library is attached then, after unattaching or purging
> the IFERR library leads to the replacement of IFERR structure by
> XLIB 1793 0 object.

This is not a defect, it's the correct behavior.  When you remove a library,
the 48 can no longer display by name, or execute, any commands from that
library.  The best it can do is display the library number and the command
number as XLIB n m.

The confusion here might arise from the use of "IFERR" for the name of the
new structure word, which might suggest that the library somehow modifies
the behavior of the built-in IFERR.  Actually, when you enter a program
containing IFERR, if the library is present it compiles as a (XLIB) reference
to the new version.  External libraries are searched before the internal ones,
so a library can always supersede a built-in command or structure word with
a new one of the same name.

Bill Wickes
HP Corvallis

-------------------------------------------------------

(Comp.sys.handhelds)
Item: 2397 by k36853p at saha.hut.fi
Author: [Tapani Otala]
  Subj: New IFERR and libraries in general
  Date: Tue Mar 12 1991
----------
  Resp: 1 of 1 by billw at hpcvra.cv.hp.com.
Author: [William C Wickes]
  Date: Tue Mar 12 1991

>       a) Seems that using the new IFERR posted by Dr. Wickes
>          last week screws up the indentation of RPL programs.
>          Any way to correct this?

The program decompiler built into the 48 doesn't recognize the library IFERR,
which messes up the orderly indentation.  There's no fix for this.

>       b) Seems that DETACH does not complain when attempting to
>          detach a library _not_ attached to the current directory.
>          Now, is there a _simple_ way to find out into _which_
>          directory a library is attached?

The information about which library is attached to a subdirectory is stored
in the directory, not the library.  Hence there is no simple way to
catalog library attachments.

>          I know I could use LIBS to determine whether the library
>          is _not_ attached to the current directory, but its
>          not good enough.  I suppose LIBS used with a directory
>          traversal routine could be used to locate the correct
>          directory, but its a real drag. Plus I am not entirely
>          sure about the uniqueness of the result.

This is the only way to do it; but note that a particular library can be
attached to any number of directories.

>       c) When I PURGE a detached library, the display jerks sideways
>          about one half of the screen. Is this supposed to happen?

This is normal and harmless.  The library configuration table is stored
at a lower address than the display RAM, so when the table shrinks, the
display jerks while memory is being merged.  I actually "use" this effect
to give me confirmation that the purge has actually happened.

Bill Wickes
HP Corvallis