DW> I have seen many programs that include large chunks of code that are
DW> never executed under any circumstances. The programmer had second
DW> thoughts, and never bothered to clean up after himself.
DW> I have sometimes wondered if it might be possible to do this
DW> automatically - to set up some sort of "supervisor" which would
DW> watch a  program as it is running for a long time, and take note of
DW> any bits that  are never used. Eventually, it would cut them out.
DW> But, of course, this  would probably cause problems by removing
DW> error traps and the like,  which are executed only very rarely but
DW> are very valuable when they are  needed.
     Not exactly what you said, but this could help:
    -------------------------8<------------------------
'$Title:'Source Code Cross Reference Program'
'$SubTitle:'Main Module'
'*****************************************************
'  XREF.BAS - Main Module for Cross Referencing BASIC
Source files.
'  Version 2.20
'  by Don Malin
'  (c) 1989 - 1991 Crescent Software, Inc.
    -------------------------8<------------------------
     This is a PDS written program that can be very
useful.  It analyzes "any Microsoft BASIC" program and
reports many things including variables that are never
used.  It can show where commands are used, what's
bringing in the Floating Point Library, etc.
     There is a danger is using a "supervisor" as you
mention: seldom-used parts.  Back in my main frame
days, I was awakened at about 4 AM by the mathematician
working on our computer: he'd had a failure.  He showed
me what he was trying to do and we had our usually
friendly finger-pointing: "it's your codes fault" vs
"it the machine's fault."  This guy was always doing
some esoteric math.  He taught me a bit about Matrix
Algebra, but most of it was way over my head.
     Finally, after much searching, I traced the
problem to a certain module and replaced it (I only
found bad modules, the day crew found the bad tube or
other part for replacement).  Still didn't work.
Several modules were swapped in, to no avail.
     Finally I opened the other side of the panel.  On
one pin to that module's plug, one wire was wrapped
around the terminal WITH THE INSULATION STILL ON IT and
not soldered.  That wire had never been connected to
that pin and in two years of operation no one had
called on it to operate.
     I left it exactly as it was, clipping another
piece of wire to parallel it so it would work that
night and so the bosses could see for themselves what
was what.  There was a Hell of a Storm and worries
about what wrong answers had resulted.  However, tests
showed that if it had ever been addressed, a failure
would have occurred and proved that it had never just
given the wrong answer!  Not even our maintenance test
programs had addressed it.  (They did after that.)
     This seems impossible and I don't think everyone
actually believed the test results completely.  This
same thing _could_ happen in software.  Having a
"supervisor" excise a section that's never been used in
1000000 runs, does not mean it won't be called on the
1000001st run!
  FIDO: Bill White @ 1:135/110 (Miami)
 InterNet: bill.white@110.sunshine.com
 * SLMR 2.1a * Once a year, go someplace you've never been before.
--- Maximus 2.01wb
---------------