LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
David Carlisle <[log in to unmask]>
Wed, 22 Oct 1997 12:01:46 +0100
<v03110701b073767a877c@[]> (message from Hans Aberg on Wed, 22 Oct 1997 11:44:19 +0200)
Mailing list for the LaTeX3 project <[log in to unmask]>
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.