From: Samantha Atkins (samantha@objectent.com)
Date: Tue Jul 17 2001 - 23:31:05 MDT
"Eliezer S. Yudkowsky" wrote:
>
> Samantha Atkins wrote:
> >
> > I have already written some time ago on what is wrong with
> > basing a programming language, especially in a highly critical
> > and high demand environment like an AI, in a markup language
> > designed for portable data representation. I have nothing to
> > add to that at this time. I hope someone talks you out of this
> > as I can scarcely think of a more crippled way to attempt to
> > write and maintains something as sophisticated as an SI.
>
> Right now, if you want to write code, you have two options:
>
> 1) You can write in plaintext. ASM, C++, Java, and so on all count as
> "flat text files" for this purpose.
>
> 2) You can write in LISP, a language first created during the 1950s,
> using linked lists, and later updated to use other flat list structures as
> well.
>
I can write in Smalltalk, Ruby, Python, Objective C, Haskell,
and several other languages besides. Given a powerful enough
language (like Lisp) I can generate new languages quickly and
easily to fit the problem with quite new constructs.
When Lisp was created is irrelevant. Using linked lists
internally is a huge oversimplification (and not true of
various aspects of all modern Lisp environements internally) and
not particularly relevant to its power except for its
fundamental low-level simplicity. The lists are no more "flat"
than an XML file is. Much less so as a matter of fact as
arbitrary functional expressions can be expressed within the
same simple list structure as well as macros that generate new
list structures (including new function expressions) dynamically
when invoked. You can do nothing remotely of this power
starting from such a simple base and with as simple of an
interpreter loop using XML.
Almost every computer language concept devised in the last 5
decades was first developed, prototyped and refined in Lisp.
There are good reasons for that as I hope you are well aware.
> (You can also write in bizarre Martian languages like APL.)
>
> XML, for our purposes, is not a portable markup language consisting of
> flat text containing angular brackets; it is a hierarchical, annotable,
> extensible free-flowing tree structure in which nodes have metadata. We
> need that.
Bah. I can annotate much more richly in Lisp and have the
annotation adapt itself to the context dynamically to boot. XML
is not "free-flowing". It is fairly rigid (or at least not
standardized) if you need to do something different than follow
the hierarchical layout imposed by its author. If what you
really have is some type of network or a set of realations a
fixed hiearchical form is in the way. You need to be forced
into a relatively fixed form like you need a hole in the head.
It is hierarchical. This is not a great thing for a programming
language. There are many other very useful relationships of
elements as I am sure you are aware. Using a tool that only has
one of them built-in and the rest as relatively ugly kludges is
one of the problem I have with using XML as a programming
language. It is even somewhat of a problem even using it to
represent relatively (to XML) rich data relationships.
>
> Luckily, there happens to be a standard for representing these structures
> as flat text files containing angular brackets. But that latter part
> becomes relevant only when saving objects or programs to disk, or when
> exposing Flare internals to human examination. (The programmer, of
> course, usually writes in FlareSpeak rather than typing in FlareCode in
> XML.)
>
Readying XML files is not a natural human capability. I find
them painfully stultified for all but data that happens to be
pretty hierarchical. It does not make sense to me that pushing
things into XML is more powerful than something truly flexible
for representing and building new kinds of relationships and
algorithms like lisp. And Lisp is much easier to
programmatically read and manipulate than using XML. As this
effort is primariy for building a SI capable of examining and
mutating its own code it seems natural to use a language more
geared to this and where most of the work along these lines to
date has been done.
Representing actual programming constructs in XML is even
uglier. A bunch of tags for an interpreter to parse into
something more reasonable from a language that was never meant
for expressing algorithms and never designed for that purpose is
a huge and unnecessary kludge.
Translating from FlareSpeak to FlareCode (read something
reasonable for expressing algorithms to XML which is arguable
not at all reasonable for this) and back again costs machine
cycles that I don't see how this work can afford to waste. And
you will do it pretty often as modules are swapped in and out of
the working consciousness as needed. So do you plan some other
representation as some type of VM code to make this sort of
thing at all tractable? When the interpreter interprets the
FlareCode (XML) exactly what kind of structure and internal
representation do you have in mind to hold state, already parsed
functions and so on? Or do you plan to put all of that back
into XML again and again?
> -- -- -- -- --
> Eliezer S. Yudkowsky http://singinst.org/
> Research Fellow, Singularity Institute for Artificial Intelligence
This archive was generated by hypermail 2.1.5 : Sat Nov 02 2002 - 08:08:51 MST