> This would need some kind of modality for the registers, and memory > locations... Eliezier has made some noieses about a modality for > sourcecode but he has shown no interest in sharing that with the > community as he seems hell-bent on dominating the universe himself. =\
Hmmm.... I'll make a few comments about the idea of a codic modality. The idea is certainly not original with Eliezer Yudkowsky (though the phrase may be), but it is a good idea and I'm happy Eliezer has promoted it so avidly and clearly. I have thought a bit about the codic modality before.... The first obvious conclusion is that having an AI directly observe code in "sequence of characters" form is not terribly useful. What you want to do is treat the early stages of compilation as "perceptual preprocessing." So that an AI perceives a computer program in the form of some sort of abstract data structure -- generally a tree or other form of graph. If the programming language in question is a purely functional language, this is particularly clean; the AI can then perceive code, for example, as a tree or dag (directed acyclic graph) whose nodes contain mathematical functions drawn from a small vocabulary (combinators, supercombinators, etc.). It can produce code by producing combinator dags, and having these dags automatically postprocessed into executable code (the dags can also be translated into textual form for human reading, when this is desired). The current Novamente implementation is C++. However, C++ is going to be a very difficult language to "directly perceive." Our long-term plan is to, in a later Novamente version, strip the C++ part down to a minimum, and put most of the code in a functional language (Sasha) running on top of the C++ Novamente core. The first phase of Novamente code-modality-based self-modification will be Sasha-based. Once it has gotten very good at this in an "easy" language (Sasha), it will hopefully be ready to tackle C++, by perceiving the more complex and twisted graph data structures inside a C++ compiler. When we do get to this latter stage, the open-source movement will be a good thing, as the gcc compiler is open-source and it's easy enough to expose its internal graph data structures to an AGI. But I feel pretty strongly that it makes sense to start off with functional languages which, while less efficient to execute on contemporary hardware, are a lot easier to rationally analyze than imperative languages like C++. [Human beings sometimes have trouble thinking about functional programs, but this is because of the very limited stack size of our "focused attention" ;) ... a problem AGI's need not contend with.] A "hardware modality" -- perceiving registers, etc. -- seems to me like it should come AFTER a C++ - level codic modality. In other words, I advocate starting at the most abstract level -- with perception and action in the functional-language domain. Then imperative languages, beginning with perhaps Java or C#. Then C++. Then assembler, which comes along with the hardware modality. I don't think it's a good idea to start at the hardware level... -- Ben Goertzel ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?[EMAIL PROTECTED]
