Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!apple!agate!priam.Berkeley.EDU!edward From: edward@priam.Berkeley.EDU (Edward Wang) Newsgroups: comp.text.tex Subject: Re: Why use TeX if ... Message-ID: <1991May10.065219.23433@agate.berkeley.edu> Date: 10 May 91 06:52:19 GMT References: <1991May9.164341.14084@csrd.uiuc.edu> <1991May9.204113.17636@beaver.cs.washington.edu> Sender: root@agate.berkeley.edu (Charlie Root) Organization: University of California, Berkeley Lines: 34 In article <1991May9.204113.17636@beaver.cs.washington.edu> pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes: >... >The primary difference >was the internal model - we were going to change it from "boxes+glue" >to something a little more PostScript like, and rather more reflective >of digital typesetting than the model Knuth picked. We liked to think >that were writing the TeX Knuth would have written if PageMaker had Surely the box-and-glue model is a superset of the Postscript (positioning by coordinate) model. I agree that most of the glue features wouldn't be necessary if Tex had a more complete programming language, but I don't think it really gets in the way. The parshape problem is not an effect of using boxes and glue. In fact, I think it's possible (within the Tex line-breaking model) to specify paragraph shapes by the actual shapes, rather than by list of line lengths (\parshape). Some suitable shape-description language has to be designed, however. >The hacking problem is primarily caused by the fact that the TeX >extension language was designed (apparently) as a macro replacement >language. If TeX has a "normal" or "proper" programming language, then >it would a lot easier to extend, without getting used to its >arcane grammar. I agree. I can think of three things wrong with the Tex language: textual substitution macros (rather than functions or even Lisp-like macros), dynamic scoping (lexical is better, both is best), lack of a programmer-visible representation of text (boxes are not enough). On the last point, it would be sufficient to have a side-effectless way to map text (strings as in the input document) into typeset text. As it is, the result is inconsistencies like Latex's fragile commands.