Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rutgers!sun-barr!apple!usc!jarthur!sburke
From: sburke@jarthur.Claremont.EDU (Scott Burke)
Newsgroups: comp.sys.handhelds
Subject: Re: IFERR Problem.
Keywords: iferr, error trapping.
Message-ID: <11204@jarthur.Claremont.EDU>
Date: 13 Mar 91 21:38:23 GMT
References: <27dd8a16:2405comp.sys.handhelds@hpcvbbs.UUCP>
Organization: Harvey Mudd College, Claremont, CA 91711
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.
sburke@jarthur.claremont.edu