From: Mark Waser (mwaser@cox.net)
Date: Mon Mar 15 2004 - 19:26:50 MST
Samantha said:
> That a language can map into XML and is arguably a good language does
> not give weight to the reverse proposition that an XML-based
> programming language per se will be a huge advance.
Of course not.
<Argh! break for many hours while composing and re-composing my answer . .
. :->
<let me try it this way . . . . >
<Note: there are a couple of important points for Ben at the bottom>
The short answer - I want an environment where a program is also data so
that automatic program generation and manipulation is facilitated. Making
a programming language XML-compliant pretty much guarantees this and also
gives access to a large existing infrastructure that already
manipulates/supports XML. 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. 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. 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.
= = = = =
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>
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.
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.
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
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.
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.
Note to Ben: A couple of things that I would hope for but don't yet see in
Novamente are a) ways to take recognize and advantage of the scale
invariance of many activities through encapsulation and b) a way to compile
specific time-critical schemas from more general schemas (and the reverse,
allowing for subsequent description of currently compiled code, like
CIM-dynamics, WITHOUT affecting the system).
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:46 MDT