[exprla-devel] First XPL thoughts (attached)

[reid_spencer <ras...@re...>]

--- In xpl-dev@yahoo..., Jonathan Burns <saski@w...> wrote:

Thanks to all who verified my mail. All seems well now.

Since the list is new, and has several beginners like me,
I'd like to share some general thoughts.

When I read that there was a proposal for an XML-based language,
it rang a bell - something about it seemed absolutely right.
But what? Exactly what is the advantage to be gained?

After thought, it seems to come down to these:

1. An XPL program is an XML document.

2. An XPL program operates on XML documents.

3. Put them together, and we have a reflective programming system,
   in which some programs can operate on other programs.

Now this is also true of Lisp-family languages, which also handle
headed hierarchic lists, including Lisp functions themselves.
What was missing here?

Well, obviously, programs are meant to be executed by interpreters,
while documents are supposed to be read and written, relatively
freely, by users.

A Lisp list makes a fairly horrible document to read. It could be
otherwise, if there were a standard formatting and typesetting
program, to display Lisp documents.

A Lisp list is also a horrible document to edit, because it is
easy to edit errors into the source code (all those parentheses).
It could be otherwise, if there were standard programs for finding,
cutting, pasting and editing Lisp documents, integrated into a
pleasant GUI, and preferably allowing the user to operate on
an active version of the typeset form of the document.

Neither "otherwise" was true in the days when Lisp had a wide
research community. However, the first is certainly true of XML,
and the second will be true. For one thing, the upcoming open-
source version of Netscape, Mozilla, is said to be "fully XML-
based"; exactly what this means, I am not certain, but there
will surely be support for a wide variety of text-document
style-sheets and data formatting like tables, and I would guess
that editable system parameters like menu lists will be XML
documents.

Which brings me to another reason that Lisp and related languages
failed to capitalize on simplicity and reflectivity: there was no
standard I/O interface for them to address. Java currently faces
the same problem; as soon as it addresses the file system provided
by a platform, its platform-independence vanishes, and its reflective
powers turn against its vaunted security.

However, if Netscape is your environment, and http your filesystem
interface, then as far as I can see, Apache can be your filesystem
implementation, permitting read/write privileges to HTML documents,
and that is all the capability you need for static documents.
The whole range of platform-specific security threats is thereby
nullified - although we will then have to build firewalls within
our Apache servers. (I think.)

Given all of this, I think an XPL could become an extremely
useful language for Web-content manipulation, in the same class
as Tcl, Python and Perl; and would handsomely reward whatever
effort we could give to it.


How should XPL be designed?

Above all, Interfaces. I used to be a skeptic about object-
oriented programming, but my experience with the Melbourne
Pattern Languages discussion group over the past year has
made me a believer.

That, and reading magazines mostly about C++ and Windows
programming, and about the huge struggles going on, to
define a style of programming which is both distributed and
platform-independent. Roughly, when we have data which is
tagged as being objects of a class, but the class implementation
could be anywhere in a network, then the only form of
communication known which is location- and implementation-
independent, is pure interface or protocol. Interfaces are
the currency of COM and CORBA, and I am certain that we
will only get the XML virtues into a language if we design
the language in terms of interfaces.


There's another aspect, though, which I don't have clearly
defined. What do you do with an XML document? You parse it;
that is, it's a tree, you traverse it. Unless this is the
final operation, what this gives you is another tree,
constrained by the same grammar, or a grammer related to it.

I can imagine an XPL program as a pipeline of smaller XPL
programs, modifying a document in turn, maybe with side-effects.
That's one style of programming.

I can also imagine taking a grammar, say grammar-1, and changing
one of the primitives, the leaf-tags, so that it now reads
<grammar-2-document>, within a new grammar-1.1; and thus building
ever deeper trees of data.

And I can also imagine a program that takes a grammar-1.1 document,
and reduces each grammar-2 subtree within it, replacing it with
a final grammar-1 leaf, and leaving a grammar-1 document behind.
Something of this kind is the essential interpretive mechanism of
Wolfram Research Mathematica, a rule-based expression substitution
system in which I've done a lot of work. There is also TXL, a
tree manipulation system which looks powerful, of which the older
versions are freely downloadable (not open-source, however).

I've had vague ideas for a couple of years, about designing
a Mathematica-type language based on lex/yacc, which would
apply reduction rules to a document, in the course of parsing
it. ("Bisonica" - should I copyright the name, or am I among
friends? :-))

XML would be a very apt place for working this idea out.


OK, enough for starters. Does any of this strike chords for
people here?

Goodwill
Jonno
--- End forwarded message ---