Deposing Dictators

[Stephen Horne]

On Sat, 28 Jul 2001 20:28:28 -0700, "Dirck Blaskey"
<dirck at pacbell.net> wrote:

>Unless you have compelling reasons for using XML, I would suggest
>the alternative of using Python itself as the meta-language.
>
>Maybe I don't fully understand your intended use of XML, but
>it gives me a good opportunity to go off on a tangent, as well.
>(Hmm...  Maybe it's time to change the subject: line?)
>
>XML is a bit hard on the eyes (quite unlike Python).
>I've been using Python as a meta-language, and it's kind of a neat twist.

I only see XML as a human readable language as a last resort, I agree.
And I *have* used something *based* on Python as a meta-language for
some time - I use it to generate source code for scanners, parsers and
various data structures for instance.

The thing about XML, though, is that it doesn't require Python. After
years of Python advocacy, that is suddenly very important.

There aren't many good XML editors around, I'll admit, but in
principle a tool to edit the XML could be created and I intend to keep
the level of tags required to an absolute minimum anyway - rather like
a dull HTML page.

I have thought of using XML as a more detailed semantic description of
source code as well, however. It occurred to me that XML could fairly
cleanly represent an AST (ie parse tree), and that with an appropriate
set of elements it could be used as an intermediate file for source
code translation. That is, create Perl-to-XML and XML-to-Perl and
Python-to-XML and XML-to-Perl, and given a standard *semantic*
representation in XML you could translate many programs and you could
reliably tell where semantics cannot be directly translated.

Such a file could also act as the scripting equivalent of an
executable, or a (dynamic or static) precompiled library file - you
would only need one interpreter regardless of the source language
used, and because it explicitly names the semantic a major change of
the semantics related to a particular syntax in any source language
would be irrelevant. In the context of the current division issue, the
XML would simply support 'div', 'integerdiv' and 'realdiv' elements -
it's the source codes job to be concise and readable, not the XMLs.

The files would be big, but with compression probably no too big.

Other benefits of XML are that I get the ability to infer the input
files character set and easily work with unicode for free (relevant if
Java or Jython source code is used, for instance), and that the parser
is already written so I can worry about the logic straight away.
Practical editing of large XML files is tomorrows problem ;-)