Replies to replies.

[Thomas Mork Farrelly]

On Tue, 27 Oct 1998, David Manifold wrote:

> On Tue, 27 Oct 1998, Thomas M. Farrelly wrote:
> 
> > So 'foo.c' will be all over a reflective system.
> 
> To anyone:  There seem to be many different kinds and extents of
> reflection.  Is it possible to clarify and distinguish these? 

I see reflection as the ability to modify self. In a software system,
reflection must in some way be implemented. Whether or not this reflection
mechanism should be reflective is an option. If it is, the reflective
system could redefine itself to not beeing reflective, from where there is
no way back. This way a non-reflective system is sort of a subset of a
reflective one. Also is should be possible to spesify a transition from
one reflective system to another without going breaking the boundaries of
the initial reflective framework.
 
> [snip]
> 
> What do you mean by "categorisation"?
>

The ability to recognize simularities between different things. The way
humans do this is by building an overview. Computer need to look at one
detail at the time, so this is computationally difficult. Withing software
design you often need to find the essentiallities of components and
processes in order to build good abstractions. This is effectively the
same as finding orthogonal abstractions.

Its the overview part that causes the high complexity when doing automatic
categorisation.

Mabe I just had to say that I meant "classification".

> > > > > 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
> > 
> > Agreement. If "a powerful, extensible, abstract specification system" is
> > so powerful, then why does it need to be extensible? What if it wasn't
> > powerfull at all but just extensible. Then you could make it as
> > powerfull as needed. ( it only needs an 'add_power' option :)
> 
> Good point.  But I think TUNES' power comes from scalability, which
> includes extending the system as well as limiting it (removing features).
> Orthogonality of all properties makes this possible.
> 
[]
> 
> The superlanguage is a universal representation of every other language.
> It allows you to write translators between arbitrary languages, but does
> not require them.  (Just as you can have an integer and a float without
> necessarily having a conversion between them)
>
Internally, integers and floats are represented differently, so at one
point or another, convertion is made explisitly. I don't see the point in
writing translators if you don't need them.

> 
> What I meant was: AI is unnecessary, what we need instead is OO done
> right.  Instead of writing applications with functionality presented for
> the user, they should be many smaller tools presenting their functionality
> to users and other programs alike.

Yes, OO should definatly be done right. The way I see it is that there are
no OO programs, just OO systems. So OO today is incomplete, even if the
framework is complete, because it builds on a non-OO system that is not
completely or consistently interfaceble. This problem tends to manifest
itself through the whole OO system.

I think "OO" also can be replaced by "reflective" here. I don't really see
any clearcut distinction between "OO" and "reflective" in this context. In
order to be consisten, I think, OO systems need to be reflective. If it
wasn't, that would mean that it would contain non-OO code, and this messes
up the consistency of the system, ending up in the situation of the
previous paragraph, where the interfacing to non-OO code manifests it self
as some kind of non-orthogonality thoughout the system.

The reason for non-orhtogonality is that since OO is complete it would
ultimately be possible to express even the non-OO code in the OO language.
An example of this, is the distincition of "int" and "Integer" in Java.
"int" is the non-OO abstraction while "Integer"'s are objects. And of
course "int" and "Integer" are not orthogonal. Further, the reason for
this distincition in the first place, is dirty bootstrapping.


> 
> Example, the calculator applet with most GUIs does not export an API. 
> Hmm, that's because most programming languages have integer math built in. 
> Wait, that means we have integer math functionality duplicated in our
> system once for each language, and again for the calculator applet...
> instead we want an "integer math" module with a customizable interface: It
> works with users, or with any language.
> 
> When you repeat this design with file I/O, generic data structures, and
> common algorithms you end up with huge savings in duplication of
> functionality.  The goal is for every application [and language, and
> protocol] to be designed as part of a standard library instead of as a
> single-use.  And we present the entire system as the standard library and
> let users access it directly.  That should be all the user interface we
> need: Just allowing some way of users interacting with the stuff that's
> already there.

Agree.

> 
> > Anyways, this AI trend may in the best case lead to total confusion. For
> > confirmation of that fact check out the com.ai.* discussions. No hard
> > feelings to those who would like an AI-OS. You may find that what you
> > really wanted was reflection.
> 
> ...we want the computer to do what we tell it... maybe do some stuff on
> its own without having to tell it...(but we still want to tell it how to
> figure out what to do on its own)... call it AI if you want.  I think this
I call it a fancy algorithm:)
> reuqires reflection (self-programming) as well as unifying programming
> language with user interface (see above).  Sort of what Brian was saying
> about "the computer operating at the level of the user thinking about
> programming".

Yes, there is no reason for all the different language used on computers.
I has historical reasons.


--
 ____________[ Thomas M. Farrelly ]_____________
 http://ii.uib.no/~s720   mailto:s720@ii.uib.no