on the HAL-9000

RE01 Rice Brian T. EM2 BRice@vinson.navy.mil
Sun, 11 Oct 1998 14:34:40 -0700


bugs, bugs, bugs ...
What if a product of TUNES has bugs?
	We obviously know that whatever proof-generator is developed or
improved upon, some problems will remain undecideable, and the
proof-generator cannot possibly be on-line to check every single piece
of output of the code-generator or optimizer or scheduler.  I obviously
do not refer to page-faults, stack-overflows, uninitialized variables,
incoherent modularity, or any other of the usual faults that the system
will trivially eliminate.  What I mean are the limits of the system's
logic.  If the system is going to perform dynamic compilation, with any
sort of eye for efficiency, then certain complex problems will have to
have been thought out and solutions partially-evaluated and
partially-proven either by the system or the user or a combination of
the two.  Obviously, this system will require a new programming paradigm
(as opposed to syntax), and much of the early development may center
around creating a software environment rich enough to support the
millions of casual users out there who don't want or need to 'build from
scratch' themselves.  Doesn't the project's goal of usefulness extend to
minimizing the total amount of effort by society as a whole to support
some given level of culture-wide software sophistication?  These
partial-evaluation development efforts will become central to the design
issues with which we work daily.
	What are some possible examples of logic faults about which we should
think?  The problems I see as a concern are totally unlike the problems
encountered by developers today.  I think that the central issue is
related to the software's new ability to choose program layout.  It
depends on the design strategy just how many decisions will depend on
the software, varying on the amount of logic the user gives the system
to use.
For example, if the user told the computer, "use this class of patterns
for constructing program layouts and no other", then the system merely
evaluates the container that the program specification fits into,
linearly.  The only possible mistakes are failing to recognize
non-terminating recursions or loops or improper resource-management.  In
those cases, the undecideable problems could be set aside and displayed
for the user with the debugging information, and the incorrect problems
could be handled similarly with a direct pointer to the criminal code
element.
On the other hand, if the user gives the computer graph theory to
integrate with its logic, as well as data-flow analysis, control-flow
analysis, and other higher-order tools for program compilation, or if
the user happens to perceive that the computer would not handle the
program as the user would (i.e. as the computer should) and gives the
computer an explicit, specific plan for that program (expedient, but not
useful/reusable), then the computer would be enabled to handle those
more-difficult problems.
Examples of possible problem areas:
*	real-time games, where the optimization schemes normally created for
compilers are not nearly as beneficial as a good total-pipeline analysis
with lots of statistical analysis.  re-structuring a graphics pipeline
(for that desired optimization) is most certainly beyond most users' and
programmers' average means.
*	well-packed database management systems for large data sets, include
relational databases. the system may be most efficient implementing a
matrix for a network graph, and optimized forms for sparse matrices are
not very obvious, even to the average programmer, but give great
space-time savings in many situations.
*	simple task-management/scheduling (realizing that the system has no
kernel): What kind of analysis gives a cooperative solution which
matches the user's goal at any given time?
*	real-time simulations, where the objects (possible infinite) are
subject to 'laws' or relations, but the implementation of the simulation
in the kind of form required for real-time analysis may not resemble the
object-relation model at all.
	The obvious ontological mismatch between a user's view of the problem
and the usual efficient computer solution seems to require much general
higher-order logics for the computer to use.  The nature of the Tunes
system, of course, gives an added benefit of access by the user to the
higher-order logics, therefore allowing a problem-solving system of far
greater capability than Mathematica, Maple, or the other 'symbolic
algebra systems' in use today.  And, of course, the user-interface to
these logic systems must be accounted for, by what means I haven't
figured out, yet.