On Tue, Mar 13, 2012 at 5:35 PM, Reinhard Kotucha <span dir="ltr"><<a href="mailto:reinhard.kotucha@web.de" target="_blank">reinhard.kotucha@web.de</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


On the other hand, you can't simply insert Python function calls into<br>
a text file without worrying about some concept of escape sequences.<br>
In XML/HTML angle brackets have a special meaning and you have to use<br>
special sequences of characters in order to typeset angle brackets<br>
literally.<br>
<br>
Such a file can be parsed easily with regular expressions, of course.<br>
But there is a significant difference between XML/HTML and TeX.  While<br>
XML/HTML has to be parsed by an external program, TeX is its own<br>
interpreter built-in.  This makes things more difficult, but it also<br>
makes it extremely flexible and powerful.<br>
<br>
If you are using LaTeX without mixing it up with plain TeX code, I<br>
suppose that you can write a parser which is solely based on regular<br>
expressions and an EBNF specification indeed.  \catcode is not an<br>
official LaTeX command.  Though the EBNF spec has to be extended<br>
whenever an external package is loaded, the same is true for XML.<br>
<br>
As far as Lambda calculus is concerned, IMO it's not bad that it's<br>
supported somehow.  I have the impression that Knuth was inspired by<br>
functional programming languages when he designed the scripting<br>
interface, and I'm convinced that this was not a mistake.<br>
<br>
Sure, it would be much easier to have a static document with static<br>
markup tags and a program written in a language like Python, which<br>
transforms the content to PostScript or PDF.  This approach would be<br>
context insensitive, the grammar could be described in EBNF, and the<br>
lexical scanner could be set up by regular expressions.<br>
<br>
But all these things exist already and are freely available.  We are<br>
all aware of them, so one question remains: Why are we still using<br>
TeX/LaTeX instead of XML?  There must be a reason.</blockquote><div><br></div><div>"Why are we still using TeX?" is not the question I was trying to ask---or answer. I was simply demonstrating that faithfully deconstructing TeX is several orders of magnitude more difficult than processing just about any other programming or markup language and hence it is very difficult to write a lightweight processor that can do things like count the characters that will be produced by an arbitrary string of TeX.</div>


<div><br></div><div>-Charlie</div></div>