From: Samantha Atkins (samantha@objectent.com)
Date: Mon Mar 15 2004 - 23:23:49 MST
On Mar 15, 2004, at 6:26 PM, Mark Waser wrote:
> The short answer - I want an environment where a program is also data
> so
> that automatic program generation and manipulation is facilitated.
Lisp fits the bill admirably.
> Making
> a programming language XML-compliant pretty much guarantees this and
> also
> gives access to a large existing infrastructure that already
> manipulates/supports XML.
There is a lot more infrastructure that supports the second oldest
computer language which was largely tailored for AI over decades. The
XML infrastructure is for manipulating data stored in XML format. It
was not designed for writing, reasoning about or transforming
functions. Nor is that infrastructure written in XML itself. So XML
is not complete in the sense that a language like Lisp is.
> More importantly, I want the programs running
> in that environment to be efficient and scalable through the use of
> native
> data
> space partitioning and compilation of programs/functions which are
> swappable
> via package/program/function specifications.
Still sounds like Lisp comes a hell of a lot closer to me.
> There is no existing
> combination of language and environment that does all of this but I
> believe
> that given the popularity and current specification and infrastructure
> of
> XML, it could be done most quickly if the language were XML-compliant.
So, that XML is popular says that doing something XML was not designed
for in XML will make it more likely to be done well?
> In
> LISP, a program is also data but efficiency and scalability
> (particularly
> swappable modularity with compilation) are not built into the
> environment
> and LISP doesn't have nearly the audience or the infrastructure that
> XML has
> to support new development.
I do not understand why you believe that XML has "swappable modularity
with compilation" but XML does. I am not sure how the heck you are
parsing that phrase to make that work. XML doesn't even contain itself.
It requires other tools and languages to do anything with it at all.
Except for a small core, a language like Lisp is very self-contained.
Lisp is as efficient in its compiled form as C with a bit of care. It
is quite scalable. To argue that it is not would be effectively to
argue that no languages are scalable as every other language can be
expressed in Lisp. That is rather a lot of power.
> = = = = =
> The long answer
>
> Any procedural computer program/function can be represented by
> recursive
> data structure composed of a series (list) of statements that are
> themselves
> programs/functions. XML has no problem representing this as follows:
> <function name="main">
> <vars>
> <var name = "inString" type="string" />
> </var>
> <list>
> <function name="first" />
> <function name="second">
> <var name = "secondvar1" type="integer" value="1" />
> <var name = "secondvar2" type="string"
> referent="inString"/>
> </function>
> <function name="third'>
> </list>
> </function>
>
This is trivial and irrelevant to real programming and reasoning about
programs. It is also not really very applicable to functional
programming. Yes, I know you could write XML that looked sort of like
the syntactic structure of functional programs. But so what?
Write me a function that returns a function in XML alone (no external
code allowed). For that matter, write me a function that does any
computation at all in XML alone. This is why I find this discussion
so amazingly strange. It is an argument that a language that can only
encapsulate data is somehow better than real programming languages.
It is an argument stuck at the level of language syntax. If you want
to write the text of programs in XML I will think you rather strange.
But please do not confuse text with actual functionality or utility or
expressive power.
> Well, actually, there are A LOT of decisions to be made as to how all
> sorts
> of things should be represented . . . . .
>
> My point, though, is that any procedural language program COULD be
> represented in XML syntax fairly easily.
So why limit yourself to only procedural languages?
The interesting questions are not whether you could bastardize the
syntax of procedural languages into XML form but whether this would
actually buy you anything worth the trouble.
>
> ASIDE: If one wants to go down the functional programming path,
> programs
> are even more easily be represented by hierarchical tree structures
> and XML.
> Also note that procedural programs can be transformed into functional
> programs simply by realizing that series/lists are themselves composed
> of
> and can be replaced by functions)
>
> Now, what does all this buy us?
>
> First, there already exists substantial infrastructure for parsing XML,
> moving it in and out of various datastructures, etc., etc.
Most of it clumsy and woefully inefficient.
>
> Second, now that our programs already exist in a DATA format, we
> already
> have a lot of the tools that we need to be able to modify them.
>
> Now, if I were Samantha, I would argue that all of these things could
> be
> done in LISP and I would be correct. But what's generally missing in
> LISP
> is a lot of what's required for true SPEED and SCALABILITY or, as Ben
> puts
The burden of proof is on you to show anywhere near the speed and
scalability for an XMl based language that has already been
demonstrated by Lisp. You keep asserting that XML beats Lisp in this
regard without a shred of evidence or argument for support. This will
not do.
> it
>> Separate *efficiency of implementation* from *logical structure of
>> programs*. In other words, have a language with two layers: one layer
>> that is more like a formal specification, and the other layer that is
>> transformed to be efficiently executable. It's the first layer that
>> can usefully be represented in XML, and potentially manipulated using
>> XML-manipulation tools.
>
> Actually, what I envision when I talk about an XML-based language is
> more
> like XML.NET i.e. a system where I can write a description of a
> program or a
> function in my language but compile it down to or replace it with an
> implementation-efficient version.
>
> IMPORTANT POINT: If I were Ben and working on Novamente, I would be
> making sure that my freezing and thawing (storage and retrieval) of
> schemas,
> atomspaces, etc. was available through XML and that Sasha 2's syntax
> was XML
> compliant.
>
Need I point out that XML itself is trivial to represent in Lisp and
Lisp has built into it vastly more data expressive power than XML
dreams of? Or that the result is immediately computable? There is
less separation, less "impedance mismatch" if you will, in a language
like Lisp.
> The whole point to this is to try to make a very modular, swappable
> programming environment that lends itself to both very high levels of
> abstraction and drilling down to the lowest detail when necessary.
>
In XML the abstraction will come from outside XML. In Lisp, the
abstraction is built up within the same language and environment with
tranformations between the levels of abstraction and cross-cutting
across the levels all available in the same language. I don't see how
a lot of dead XML data representation plus various types of
manipulating code in one or more other languages (yes, the in-memory
representation is another language) can possibly compare in elegance,
flexibility or power.
- samantha
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:46 MDT