Date: Wed, 13 Mar 1991 22:34 CST
Subject: Re: IFERR Problem.
Organization: Harvey Mudd College, Claremont, CA 91711
Keywords: iferr, error trapping.
Article-I.D.: jarthur.11204
Lines: 26


Regarding the problem about the new IFERR library over-riding the built-in
command IFERR:  That's just how it works, and is a _desired_ feature!  It
simply means you must be careful when you are downloading your source code
to the HP-48SX that you have the proper libraries installed.

Personally, I would have preferred that the new IFERR library come out with
a different name, because I am not about to revise the thousands of lines of
code I have written which make integral use of the old IFERR, and if I were
to download that code to the 48 with the new IFERR installed, I would be in
trouble.  (in fact, I did this once and got a big surprise!)  In the future,
I will use the new version, but it would have made most sense to me to call
it IFERR2 or something like that.  Anyways, it's not a stumbling block,
which is why this is not a serious suggestion for change to HP; I simply
don't install the library unless I'm developing code which makes use of it.

By and large, there are few conflicts like this one, because most libraries
use command words that don't overlap with the 48.  (I did find that Jim
Donnelly's Toolkit uses EXTRACT, as does the library posted a while back to
do USRLIB stuff on the 48...)

One thing to remember if multiple libraries are in place with the same names
is that the _highest_ library ID number will be searched first.

Scott.

Date: Thu, 14 Mar 1991 07:21 CST
Subject: Re: IFERR Problem.
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Article-I.D.: hpcvra.25590124
Lines: 22

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