Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!swrinde!mips!spool.mu.edu!uunet!mcsun!ukc!edcastle!aiai!aipna!cstr!tim From: tim@cstr.ed.ac.uk (Tim Bradshaw) Newsgroups: comp.text.tex Subject: Re: TeX - The Language (Was Re: Why use TeX if ...) Message-ID: Date: 15 May 91 20:48:14 GMT References: <1991May10.065219.23433@agate.berkeley.edu> <1991May10.211802.4344@csrd.uiuc.edu> <1991May11.013248.16286@nntp-server.caltech.edu> <1991May13.204709.20365@beaver.cs.washington.edu> Sender: news@aipna.ed.ac.uk Organization: CSTR, University of Edinburgh Lines: 153 In-reply-to: pauld@stowe.cs.washington.edu's message of 13 May 91 20:47:09 GMT [ This is a followup to several threads that seem to have become split, so is probably confusing -- I wish news could work as a DAG rather than a tree. I also missed the beginning of the thread, but it seems to have my name in it at various points (hey, fame!), so I feel justified in slightly random comments! It's also very long for which I apologise. ] As far as I can see, people are arguing about TeX's macro language, and comparing it to various other systems. I should make my position clear: I find TeX the most arcane and unpleasant system to use I have ever seen, assembler included. I've written fairly considerable (though small cf some other readers of this group I'm sure) things in TeX, and even when I did it practically full time for months I still ran into behaviour that I could spend a day or more trying to understand. It says something that latex.tex has the algorithms as comments: not comments in the code explaining what is going on, but the whole thing written out more comprehensibly. * So: comments on what people have said: marcel@cs.caltech.edu (Marcel van der Goot) writes: > As far as I can tell, the only way in which you can have the freedom of > presenting your input as almost plain text, with very little knowledge > about the details of the underlying programming language, is with a > language based on macro substitution. A conventional programming language > with strict syntax means that your input has to obey very strict rules. This is perhaps true *if* you insist, as TeX does, on inlining the programming language with the input to the resulting program. While this is the way that typesetting systems have worked historically, I think it is very unfortunate. Once you stop doing this then you can have a programming language that looks however you want it to, and an input stream likewise: I don't have to type Emacs lisp at emacs to use it as an editor. > It is true, TeX's macros take some getting used to, because of the complexity > of the system. What you get back for that is an unparallelled freedom in > the form your (normal text) input can take. I wish you did! Other people have mentioned some of the limitations. > You can make TeX look like > LaTeX (which is only somewhat different), but you could for instance also > make TeX look like troff. With a normal programming language that > is impossible: A C program always looks like a C program, a pascal program > always looks like a pascal program, and a lisp program always looks like > a lisp program. You cannot decide, ``let's give an end-of-line the meaning > of a semi-colon'' so that you don't have to write semi-colons in C; You > cannot decide to use square brackets instead of parentheses in lisp. And > these are only very minor variations, many TeX macros do much more. Don't know too much about what you can do with C. You can make Lisp (by which I mean Common Lisp) look like whatever you like modulo some stupidities in the design of the reader which are now fixed. I use the Lisp reader to read stuff that looks like: `*o-bar | {*r *rr} *# -> oo.'. Prolog people seem mostly to work by redefining the syntax to be some suitable grammar formalism. > For those people the > ease of *usage* of the macros is important; TeX can make that very easy. Really? The users who complain to me about how difficult LaTeX is disagree. Most of the problems could probably be fixed by redoing LaTeX, but some problems are not fixable. The worst problem is the absence of any kind of error system. *However* carefully and cleverly you define the input syntax, people are going to get it wrong: when they do you should be able to catch the error, work out what caused it, and at the very least print some kind of useful message suggesting a fix. In particular you should be able to trap errors produced by the system itself and print something more sensible than `overfull hbox'. Preferably you should be able to define ways of continuing from classes of errors. > Of course, that means that the *construction* of macros becomes more > complicated. Well it's certainly complicated. > When TeX is compared with other programs/systems, one should keep in > mind what TeX is intended for. Since TeX is intended for typesetting > books and the like, it should not be compared as if the primary use > of TeX is as a programming language. While this is off the point I am trying to make I think it's anm extremely important thing to bear in mind when fighting TeX. Knuth wrote it (I suspect) to typeset one particular series of books in one particular way. It's amazing that it *is* so generally useful when that is borne in mind. pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes: > Trying to use TeX's macro language to enable > users to have greater ease-of-use when inputting TeX is like trying to > use Fortran to implement linked lists or other pointer-based data > structures: you can do it, but it costs and its cumbersome. Ha! wonderful! Actually you can't do it anyway, not without dynamic memory allocation. * And ideas on how it might be: Although TeX is the only system I know of that's really any good for serious typography, I think it has problems that are not fixable, especially now it is frozen. These are in two places: The language is horrid. Probably for several reasons but at least a factor is this business of inlining code and data. TeX's model of the world isn't powerful enough to do more than it was designed to do -- why should it be? Unfortunately people now *want* to do more than it was designed to do. So I think in due course some successor for TeX is needed and will appear. I am interested in what such a system might look like. Here are some characteristics I think are important: Text and programming should be separate (see above). It needs to be extensible: this means a real programming language. In particular I'd like good error handling including user-defined error classes &c. I'd also like at least some kind of object-oriented system, so I can specialise things that already exist rather than reinventing them. It needs to be *dynamically* extensible: I want to be able to load code into a running system (like TeX can). It needs to have no limits: I don't want to have to recompile the system when I run out of nesting depth. Even PCs can now run big programs and do dynamic memroy management I hope. It needs to produce output as good looking as TeX can (but I want to be able to change the line-breaking algorithm if need be!). It needs a more flexible model of the world than TeX has, so I don't have to use scissors and glue so often. Paul mentioned TinT (disagree about the capitalisation btw Paul!): this was the result of some early ideas along these lines. I have millions of other ideas of how things should be done but this article is too long already. I think however that it is important that people discuss these things: that way perhaps whatever replaces TeX will be some good. --tim Tim Bradshaw. Internet: tim%ed.cstr@nsfnet-relay.ac.uk UUCP: ...!uunet!mcvax!ukc!cstr!tim JANET: tim@uk.ac.ed.cstr "...wizzards & inchanters..."