162
310
TUGboat, Volume 32 (2011), No. 3
however, is much less of a concern to us because prac-
tically all L
A
T
E
Xprograms are inherently portable
(T
E
Xitself being mostly a virtual machine). A much
more important question for us is the question of
extensibility and more generally, intercession.
By extensibility, we mean to answer the follow-
ing question: given a package that does almost what
a specific user wants, is it possible to make this
package provide the requested functionality without
modifying its internal implementation? If the an-
swer is yes, then the package (or at least one of its
functionalities) can be said to be extensible. In this
context, one of the purposes of a coding style is to
help provide more, and better extensibility.
Unfortunately, full extensibility is only a utopia
because ultimately, the specific desires of a user are
completely unpredictable. In such situations, a pack-
age may need to be internally modified. This is
what we call “intercession”. The terminology comes
from the more general field of so-called “reflexive”
languages [10, , 14]. Roughly speaking, a reflexive
language provides the ability to reason about the
program itself (procedural reflection) or even the
language itself (behavioral reflection). Reflection is
usually decomposed into “introspection” (the ability
to look at yourself) and “intercession” (the ability
to modify yourself).
While extension is usually a matter of user–
package interaction, intercession is usually due to
inter-package interactions. In the L
A
T
E
Xworld, we
can identify three major sources of intercession.
1. LAT
E
X core modification: a package needs to
modify L
A
T
E
Xitself in order to provide the re-
quired functionality.
2. Packageinter-compatibility:apackageneedsto
co-exist with another package, and this requires
modifications in either or both of them.
3. Packageconflict:two(ormore)packagesinter-
cede on the same piece of code but in different
ways, or one package modifies some code and
another package is not made aware of these mod-
ifications. In both cases, compilation breaks.
Every L
A
T
E
Xuser faces the “package conflict night-
mare” one day or another [19], to the point that this
is probably the major gripe against it these days.
Consequently, we would hope that a proper coding
style addresses this issue, for example by providing
design patterns for graceful inter-package compati-
bility handling.
1.2 Consistency
One final keyword that appears quite a lot in discus-
sions on coding style is “consistency”. Given the fact
that there is much personal taste in a coding style,
consistency means that the exact coding style that
you decide to use is actually less important than the
fact of sticking to it. A person not familiar with your
coding style can probably get used to it, provided
that it is used consistently in the whole source code,
and that for example, similar situations are identifi-
able as such because the same idioms are used in all
of them.
1.3 30 years and no style?
Since more or less official coding standards seem to
exist for many programming languages and commu-
nities, one can’t help but wonder why, after 30 years
of existence, the LAT
E
Xcommunity still doesn’t have
any. Several reasons come to mind.
1.3.1 Learning by example
LAT
E
Xis not a real programming language. It is not
even a macro expansion system. LAT
E
Xis a library: a
macro layer written on top of T
E
X. Because of that,
the purpose of L
A
T
E
Xcan be anything you might want
to do related to typography, which can eventually be
expressed in terms of T
E
X. Consequently, it is im-
possible to write “The L
A
T
E
Xprogramming language”
book and in fact, this book doesn’t exist. The things
that such a book would have to describe are infinite:
they depend on every user’s goal. Note that the
L
A
T
E
XCompanion [12] is not a L
A
T
E
Xprogramming
book. For the most part, it describes some of the
core functionalities, plus a lot of package features.
This explains why learning by example is an
important process in the L
A
T
E
X community. It is
quite easy to backtrack from a particular feature to
the way it is done: you just need to look at the im-
plementation. As a result, many LAT
E
Xprogrammers
(especially newcomers) start by actually looking at
what other people did before us, copy-pasting or im-
itating functionality until they reach a satisfactory
level of understanding. In doing so, they also implic-
itly (and unconsciously) inherit the coding style (or
lack thereof) of the code they are getting inspiration
from. This behavior actually encourages legacy (the
good and the bad) and leads to a very heterogeneous
code base.
1.3.2 Lack of help
Because it is only a macro library, L
A
T
E
X is not a
structured language but a very liberal one. By pro-
viding such paradigms as object-oriented, functional,
logic, declarative programming, etc., traditional lan-
guages provide support for some “elements of style”
by construction: the choice of a specific program-
ming paradigm already imposes a particular design
Didier Verna
