## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Condense Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> From: David Carlisle <[log in to unmask]> Date: Wed, 22 Oct 1997 12:01:46 +0100 In-Reply-To: (message from Hans Aberg on Wed, 22 Oct 1997 11:44:19 +0200) Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> Parts/Attachments: text/plain (63 lines) > This makes only sense if the syntax LaTeX is published and official, and > not only used as an internal guiding line for LaTeX developers. For L2, the syntax for document authoring' is more or less published and official, namely mandatory arguments in {}, optional arguments in [], option lists comma separated and environments in \begin\end. (With a note in Leslie's book somewhere to the effect that experts may sometimes abbreviate a single token mandatory argument by missing off the {}). The syntax and structure of the programmers interface in L2 is, as you know, rather less clear. 2e tried at least to document some explicit interfaces such as the package/option handling stuff and the font declarations, and also converted all the source code comments to doc' format. (But as much of that conversion was automatic from the original ascii comments, it is not always beautiful or as well structured as you might hope). In a new system one would hope to do rather better and document the structure and syntax of all the programmers commands, and give guidelines so people know what syntax conventions to follow for new commands. ie people don't have to read through 550 pages of source2e.dvi to discover the for-loop \@for, (and to discover it has a strange :=' separated argument structure quite unlike the rest of latex) However it really is only feasable to do that for a completely new system. If you build on the current system (as we did for 2.09 -> 2e) then you gain in keeping existing users more or less happy, but you lose by keeping a large quantity of basically undocumentable coding conventions that have built up over time. > I really think that a better syntax would help mathematical authoring. I > use it myself. For example, one can use name overloading, You can, but as I say that makes it difficult (perhaps) to convert the source to something else. A common requirement these days is to take latex math markup and try to force it into some other system, maybe MathML or some other web math DTD, or a symbolic algebra package such as mathematica or maple etc. If latex package authors add () delimited arguments, or other variations then it makes such uses increasingly difficult. Of course a specific extension to support ( ) delimited arguments could probably be easily accommodated, what is harder is to support arbitrary argument syntax, in the style of \def\foo#1[#2\par#3#{} so having some command defining mechanism, more general than \newcommand but more restrictive than \def may be a good thing. > So now you are saying that tools that are supposed to simplify LaTeX > authoring, in fact may make it more difficult... That is of course a fact of life:-) but the systems I am thinking about are not primarily for *authoring* latex (gnu emacs being the one true authoring system). They are *consumers* of latex. SW will parse a latex math expression written by hand' and pass it to maple to be evaluated, but you need to give it a chance by not making arbitrary syntax changes. I am not saying that such systems have total control over latex development, but I think that any discussion of syntax proposals needs to bear in mind such issues as conversion to other formats, not just be viewed as a matter of convenience for author markup for the traditional' edit->tex->preview->print cycle. David `