Reflecting on reflective computing.

[Tril]

On Fri, 23 Oct 1998, Christopher Barry wrote:

> AI is what you need to prove program correctness.

No.  Intelligence is required to generate proofs of program correctness in
many cases.  There will always be a case where humans are required, no
matter how elaborate or intelligent of algorithms are used.

> Two linear streams in parallel ain't no better than one, just 10 times
> more of a hassle to set up for debugging....

Exactly.  A "program" is a large sequential list of instructions.  Why
should people be forced to program this way?  It's not intuitive.  Doing
so is the reason programming is so hard and time-consuming.  It's also why
learning to use a computer is so difficult.

TUNES allows programmers to specify exactly what is required by what, and
what is not, including which instructions REALLY have to be executed
before which other instructions.  Any instructions that have no dependence
can be run in any order, or at the same time.  (Instructions here can mean
a command of any level not just machine language)

> > And the OS should adapt to
> > hardware limitations, and not provide any static requirements for
> > applications so that no software limitations are induced.
> > 
> The OS not provide any static requirements for applications so that no
> software limitations are induced? If Tunes does not provide static
> requirements, then it provides either dynamic requirements or no
> requirements, does this make sense? In what sense do you mean software
> limitations? This is a cryptic statement as I've interpreted it.

In Win32 you must access the internals of the system using the Win32 API
and a C++ calling convention.  In Linux you must use standard library
headers and a C calling convention.  Also, the virtual memory environment
in which programs run is fixed, and cannot be adjusted for each
application individually.  These "requirements" force people to develop
entirely new systems, because they can't do what they want within existing
ones.

> [The Hurd]

I read into your words that you think TUNES will take even longer to
implement than the Hurd because it is more ambitious. Who cares?  Why is
imlementation time relevant at all?  From what I hear , there are many
people who are very happy with the state of current systems, yourself
included, who aren't in a hurry to get TUNES.  Why should I be?

> [UI]

The main requirement for any human-computer interaction is that it be
orthogonal to any functionality.  You should be able to plug different
"UIs" into "application modules" to get different "paradigms" of
interacting with the same "features".

> > > > * Went toward figuring out how to optimize special cases to get decent
> > > > performance.
> > >
> > > This seems kind of unavoidable, unless I misunderstand the sense of what
> > > you mean.
> > 
> > I was sort of unclear.  I meant when you actually redesign your entire
> > program to get an efficiency boost.  Code that is efficient for the
> > machine is not always maintainable.  AOP (aspects), or the more general
> > orthogonalization of specification and implementation, solve this.
> 
> I'll agree to this, and it is one of many important, possibly achievable
> goals. But you've got to define clear steps to reach the above goal and
> define sub-goals. Talking about the ideal system on a mailing list for 5
> years and not writing a hell of a lot of code or complete specifications
> so that code can be slapped out ain't gonna get a whole lot done.

Orthogonalization of specification and implementation:  The specification
is given priority.  Implementation is dynamic, changing based on resource
constraints, but always conforming to the specification it is attached to.
A specification is a high level description of something.  The
implementation is a mapping from the description onto the low level
machine's domain.  Generation of the implementation is attempted
automatically, and uses hints from the human when necessary.  In addition,
the implementation can be adjusted manually to override the automatically
determined parts when you have better ways or just want to try something.

The system will be complete when these goals are accomplished:
* a powerful, extensible, abstract specification system
* extend it to specify low-level hardware
* extend it to specify translation from itself to low-level hardware
 
> > > Do you mean optimizing in the sense of say special hardware cases
> > > (presence of MMX unit or deep pipeline), or software, like case N=13 for
> > > an algorithm or system=SysV? Or perhaps both? In any case if the system
> > > you guys are making has the intelligence to automatically optimizes
> > > programs and algorithms for all relevant special cases that the
> > > programmer would be interested in automatically, well, good luck.
> > 
> > Both hardware and software.. but there's no magic to optimizing.  Allow
> > automatic optimizations where they work, but allow users/developers to
> > specify information necessary at any level to provide the structure they
> > want.
> >
> 
> That was a mighty vague statement. But no point in picking this apart,
> bigger fish to fry ahead....

I think this is clarified above, under "orthogonalization of specification
and implementation."  Optimization is simply choosing one possible
implementation because it meets certain criteria better than other
possible implementations.

David Manifold <dem@tunes.org>