Samantha Atkins wrote:
>
> 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.
This is something I just don't understand at all. What do you mean, I
can't do this in XML? I can do this with raw lists but not with XML? Why
on Earth not? When I was young and inexperienced I wrote my own
parser-interpreter on at least two occasions, and I can personally attest
that it is both easy and natural to represent code blocks and expressions
as tree structures which are then directly executed by the interpreter.
Not supernaturally efficient, perhaps, but not too slow either.
In fact, I believe that LISP code effectively does this as well; LISP
expressions may not be *extensible* tree structures (if you can cons
another element onto '(plus 2 2) without breaking it, even under
object-oriented Common LISP, I'd like to know how), but LISP expressions
are most certainly tree structures and not Java VM or assembly. '(plus 2
(plus 1 1)) sure looks like a tree structure to me.
> Bah. I can annotate much more richly in Lisp
??
> and have the
> annotation adapt itself to the context dynamically to boot.
Funny, I don't remember that idiom being built into lists. What's that
you say? It's built into the language interpreter, not the
representation? Well, why wouldn't Flare be able to do that as well? And
do it far more naturally with XML than with lists.
> 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.
I don't see why Flare would have trouble representing non-hierarchical
data. Flare has references, so it can freely represent directed networks
and cyclic structures.
> 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.
Okay, this is new. LISP would be superior to Flare? I have to admit that
I've never heard that one before.
Lists are only the foundation of LISP. There's ever so much more to the
language. This I know. But LISP is still ultimately built on the idiom
of lists. There's more to Flare than XML, but Flare is still ultimately
built on that foundation. And XML is a better foundation than lists,
because you can add new pieces of data without destroying the integrity of
existing data. With a list, it takes work to enable annotation as a
special case; with XML, it is universal.
> 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
FlareSpeak never even exists except when a human programmer is looking at
code. It is inelegant to ever write FlareSpeak to disk unless it is for
debugging purposes.
FlareCode's tree structure, I expect, will be directly executed by the
interpreter. Possibly there will later be optimized representations of
FlareCode; but, like I said, I can personally attest that it is possible,
and in fact very natural, to build an interpreter that represents
statements and expressions as tree structures, and LISP seems to get along
fine by doing so.
-- -- -- -- --
Eliezer S. Yudkowsky http://singinst.org/
Research Fellow, Singularity Institute for Artificial Intelligence
This archive was generated by hypermail 2b30 : Fri Oct 12 2001 - 14:39:49 MDT