AGI *really* needs an environment that comes with reflection and metadata support (including persistence, accessibility, etc.) baked right in.
http://msdn.microsoft.com/en-us/magazine/cc301780.aspx (And note that the referenced article is six years old and several major releases back) This isn't your father's programming *language* . . . . ----- Original Message ----- From: Stephen Reed To: [email protected] Sent: Friday, October 24, 2008 12:55 PM Subject: **SPAM** Re: [agi] On programming languages Russell asked: But if it can't read the syntax tree, how will it know what the main body actually does? My line of thinking arose while considering how to reason over syntax trees. I came to realize that source code composition is somewhat analogous to program compilation in this way: When a source code program is compiled into executable machine instructions, much of the conceptual intent of the programmer is lost, but the computer can none the less execute the program. Humans cannot read compiled binary code; they cannot reason about it. We need source code for reasoning about programs. Accordingly, I thought about the program composition process. Exactly what is lost, i.e. not explicitly recorded, when a human programmer writes a correct source code program from high-level specifications. This "lost" information is what I model as the nested composition framework. When a programmer tries to understand a source code program written by someone else, the programmer must reverse-engineer the deductive chain that leads from the observed source code back to the perhaps only partially known original specifications. I will not have a worked out example until next year, but a sketch would be as follows. In Java, a main body could be a method or a block within a method. For a method, I do not persist simply the syntax tree for the method, but rather the nested composition operations that when subsequently processed generate the method source code. For a composed method I would persist: a.. composed preconditions with respect to the method parameters and possibly other scoped variables such as class variables b.. composed invariant conditions c.. composed postconditions d.. composed method comment e.. composed method type f.. composed method access modifiers (i.e. public, private, abstract etc.) g.. composed method parameter type, comment, modifier (e.g. final) h.. composed statements Composed statements generate Java statements such as an assignment statement, block statement and so forth. You can see that there is a tree structure that can be navigated when performing a deductive composition operation like "is ArrayList imported into the containing class? - if not then compose that import in the right place". Persisted composition instances are KB terms that can be linked to the justifying algorithmic and domain knowledge. I hypothesize this is cleaner and more flexible than directly tying lower-level persisted syntax trees to their justifications. -Steve Stephen L. Reed Artificial Intelligence Researcher http://texai.org/blog http://texai.org 3008 Oak Crest Ave. Austin, Texas, USA 78704 512.791.7860 ----- Original Message ---- From: Russell Wallace <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, October 24, 2008 10:28:39 AM Subject: Re: [agi] On programming languages On Fri, Oct 24, 2008 at 4:10 PM, Stephen Reed <[EMAIL PROTECTED]> wrote: > Hi Russell, > Although I've already chosen an implementation language for my Texai project > - Java, I believe that my experience may interest you. Very much so, thank you. > I moved up one level of procedural abstraction to view program composition > as the key intelligent activity. Supporting this abstraction level is the > capability to perform source code editing for the desired target language - > in my case Java. In my paradigm, its not the program syntax tree that gets > persisted in the knowledge base but rather the nested composition framework > that bottoms out in primitives that generate Java program elements. The > nested composition framework is my attempt to model the conceptual aspects > of program composition. For example a procedure may have an initialization > section, a main body, and a finalization section. I desire Texai to be able > to figure out for itself where to insert a new required variable in the > source code so that it has the appropriate scope, and so forth. But if it can't read the syntax tree, how will it know what the main body actually does? ------------------------------------------- agi Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: https://www.listbox.com/member/?&; Powered by Listbox: http://www.listbox.com ------------------------------------------------------------------------------ agi | Archives | Modify Your Subscription ------------------------------------------- agi Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: https://www.listbox.com/member/?member_id=8660244&id_secret=117534816-b15a34 Powered by Listbox: http://www.listbox.com
