Reflecting on reflective computing.

[Christopher Barry]

Tril wrote:
> 
> On Thu, 22 Oct 1998, Christopher Barry wrote:
> 
> > David Jeske wrote:
> > > I wish I could find the original Tunes 'example problem', about the
> > > "cd database", however, I can't. Can someone else provide the URL.
> >
> > Yes, I'd like to see this.
> 
> The CD Database example is at:
> http://www.tunes.org/doc/Review/cddb.html
> http://www2.tunes.org/doc/Review/cddb.html

I checked it out, and I have a large number of criticisms of it. So many
in fact, that I'll perhaps address it in another post. But if you want
the gist of what I'd have to say about it, I think if you think Real
Hard about the wistling a tune to access a song on the database example
and exactly what needs to be done to meet that end (don't use a bunch of
abstract Tunes and OO concepts to describe how this is done when you
think about it, but think about the nitty gritty instead for a change.
Like reflection? Well try and reflect on the real world programming
experience you have and then think about this Real Hard).

> 
> > > In Tunes, the idea is to remove all the 'implementation' dependent
> > > work in the above picture. To draw a half-correct analogy, you would
> > > merely ask Tunes to "run your kernel in a software emulation
> > > environment", and it would do the rest of the above stuff for you. It
> > > might need to know where to map input and output devices to (like the
> > > emulated PC's screen), so it would either make some safe-choice, or
> > > ask you what you wanted it to do.
> >
> > I have no idea how on earth Tunes could do this, or what this would look
> > like or how you would do work with it, what work Tunes would do and what
> > you would do.
> 
> The hardware platform is implemented as high level objects, which means
> you can access it like any other object.  Therefore, you can simply (from
> the user/programmer's point of view, perhaps not so simply for us) replace
> an actual 386 CPU object (that provides an interface to the physical CPU)
> with a "fake" 386 CPU object, which acts exactly the same only is more
> interpreted.  Likewise with objects for the memory, IRQ subsystem, I/O
> ports, and other hardware.  The reason this is reflective is that the 386
> CPU object isn't the "base" on which all the rest of the system depends.
> Instead, the objects that define a CPU are built of logic.  But
> implementation of logic may depend on the same CPU.  So the system
> dependency is infinitely circular.  The tricky part is making it possible
> to break the dependency in an arbitrary place, make a substitution, and
> then seal the system back up again.
> 

This is quite fascinating to think really hard about, but I don't know
how possible it would be to actually do this, when I think Real Hard
about it and try and not hide Methods with Abstracts when I think about
it.

> > No, I have an idea about how it could be better, but the same processes
> > no longer apply to make it any better, and there are no more trivial
> > things to improve, IMO. But I don't see how Tunes solves some of the
> > fundamental AI problems that need addressing for real progress.
> 
> Perhaps you could list the problems in AI that need to be solved,

Oh Lord, everything. But compiler and language technology foremost.
Using current compiler and language technology, a better compiler and
language technology can be created. And with that compiler and language
technology....

> then we
> can decide whether or not TUNES starts to address them.  Be warned that we
> don't include AI as part of the specification for TUNES, and we aren't
> going to go out of our way to make AI easy to do.  However, I'm willing to
> discuss the concepts with you.  But I don't even know what anyone means by
> "AI".  It's even more vague than "OO" (to me).
> 

To clear up some of that vaguery read up at John McCarthy's
introduction:
http://www-formal.stanford.edu/jmc/whatisai/node1.html#SECTION00010000000000000000

That will give you a basic understanding of what is meant by Artificial
Intelligence. The system all of you describe exhibits many modes and
aspects of intelligence, and will need tools and methods appropriately
suited to the task.

To quote you David from the top of:
http://www2.tunes.org/~dem/tunes/

"No language is suitable to program TUNES in. All languages are equally
unsuitable. Therefore, it doesn't matter which one we use."

Now why don't you read those three sentences. Is that very sound logic?

Let's look at the first sentence first. If no language is suitable to
program Tunes in, then what conclusion can we come to on what needs to
be done before we can make Tunes?

Now let's look at the second sentence. This is completely false logic,
with no rationale. I could argue with little effort that Lisp is better
suited to this task and similar tasks than assembler, or writing the raw
loadable image in machine code. I could also argue that Lisp is better
suited to this task than C, and with more difficulty still ML or some
other good HLL.

And finally the third sentence. A very weak conclusion to some false
logic. Which language you use is the first critical decision I can
isolate that you need to make to write Tunes, and which language you use
is not irrelevent.

> > > I can imagine a world where I can
> > > run some ActiveX plugin, whether or not I have an x86 processor and
> > > Microsoft Windows.
> >
> > So Tunes is Freedows to? It's gonna let you run binaries that rely on
> > the presence of many proprietary operating system libraries, providing
> > the functionality of WINE and then some? Sure, this would be cool, and
> > not require artificial intelligence, but kind of hard to do, no?
> 
> No.  In fact, there's no requirement that TUNES include support for any
> existing system.  It would be nice, and it will probably be easy to add
> once the system is done, but I'll let someone else do it.
>

A realistic design goal. Maybe we'll see some more of these soon....
 
> David Manifold <dem@tunes.org>