Hi Russell, Although I've already chosen an implementation language for my Texai project - Java, I believe that my experience may interest you. As many here already know, Cycorp's implementation language was a lisp subset during the the time I worked there. At Cycorp, I explored creating an agent control language that could be persisted in the Cyc KB. In the current OpenCyc download, the terms in that otherwise unused vocabulary are still present with a CBL... prefix. Cyc Behavior Language was lisp-like and relied upon the Cyc deductive inference engine to the maximum possible extent; e.g. to evaluate conditional expressions. My experiments with CBL led to the conclusion that the majority of the hand-coding, both program code and knowledge entry, pertained not to the target language, but rather to the abstract algorithms and domain knowledge required for the target program composition domain.
Another way to understand my hypothesis is to consider an intelligent code-generating system that knows how to write code for a reasonably complex task and to think about the perhaps small amount of that system that is implementation language specific. I hope to perform experiments in 2009 to prove or disprove this notion, using the Texai bootstrap English dialog system, under development, to create and edit Java source code. When deciding upon my own project's implementation language a couple of years ago, I shared your desire to have the system eventually program itself. For me, the numerous advantages of using Java outweighed the elegance of Lisp, the latter having source code as program mutable objects. 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. Cheers. -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: agi@v2.listbox.com Sent: Friday, October 24, 2008 2:03:11 AM Subject: [agi] On programming languages I understand that some here have already started a project in a given language, and aren't going to change at this late date; this is addressed to those for whom it's still an open question. The choice of language is said to not matter very much, and there are projects for which this is true. AGI is not among them, so I wrote up my thoughts on the matter in case they be of use to anyone. There turns out to be a website collecting perspectives like mine, so I posted it there: http://wiki.alu.org/Russell_Wallace%27s_Road_to_Lisp And copy below: I'm doing research in AI on the problem of procedural knowledge, which means dealing with (creating, debugging, reasoning about) program code. This entails dealing with code in parse tree form (other ways to specify computation turn out to be object code, so one way or another you end up coming back to the parse tree whatever the desired end product). This necessarily entails using Lisp if we define it in the broadest sense as the high-level language family that exposes the parse tree; the decision to make, then, is whether to use an existing dialect or invent one's own. So naturally, as hackers are wont to do, I chose the second option. And I was happy as a lark for a while, putting a lot of work into creating my own language, until in late summer 2008, compelled by repetitive strain injury to take a break, I thought a bit more about what I was doing. Okay, I thought to myself, instead of using an existing language that has a dozen mature, efficient implementations, thousands of users and extensive documentation, you're spending time you haven't got to spare on creating one that will have a single inefficient prototype implementation, one user and no documentation. And for what? A nicer syntax and ditching some historical baggage that isn't really doing any harm in the first place? Sharpen your wits, Russell. This is going to be a hard enough job even if you're smart about it. Making mistakes like this, you haven't a prayer. After that, the decision to use Common Lisp over Scheme was dictated by the fact that Common Lisp has the more comprehensive language standard, which makes it easy to port code (at least code that primarily performs computation rather than I/O) between implementations. The ability to defer the choice of implementation is a significant strategic advantage. ------------------------------------------- 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: 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
