4

As a mathematician, my training is to define my terms before I use them. As a computer programmer, I recognize that there are sometimes good reasons to call a method/function/procedure before its full definition has been given. But all other things being equal, I still prefer to define helper methods before they are used rather than afterwards.

However, in TeX programming, the convention seems to be backwards. A simple example of this is the following, taken from this answer:

\newcommand{\utriangle}{\text{\doutriangle}}

\newcommand{\doutriangle}{%
  \linethickness{.1ex}%
  \setlength{\unitlength}{.8ex}%
  \begin{picture}(1,1)(0,-1)
  \polygon(0,1)(1,0)(1,1)
  \end{picture}%
}

(Note: This is taken out of context; don't try to run it by itself.)

Another example is Donald Knuth's definition of the \loop ... \if ... \repeat construction:

\def\loop#1\repeat{%
 \def\body{#1}\iterate}
\def\iterate{%
 \body \let\next\iterate
 \else \let\next\relax\fi \next}
\let\repeat=\fi

Although I have not tested this, it looks to my eye as if defining \iterate before \loop would have exactly the same effect. [I honestly have no idea about \let\repeat=\fi, since I know \fi constructions can be rather finicky.]

Is this convention arbitrary, or is there a good reason for it? For instance, are there common situations in which the code will break if the helper macro is defined first?

Community
  • 1
Charles Staats
  • 19,514
  • I have a feeling we've been asked this before :-) In general in TeX, the answer is 'order will not be important', but there are some cases where order might have an influence (e.g. if an \edef is used). – Joseph Wright Mar 09 '14 at 18:03
  • 1
    From a readability standpoint, it is a question of deductive vs. inductive; first, give the macro you are trying to make, then give the other macros that enable that one. Otherwise, you are left with (sometimes) tens or hundreds of lines that are somewhat indecipherable until you get to the bottom and see, "Oh, we're making \utriangle". – cslstr Mar 09 '14 at 18:03
  • @cslstr: Unless your training is to scan through the paper code until you see the part you care about, and then work backwards. Either way, if readability is important, I imagine giving informative names to the helper macros is crucial. Knuth's example above does a fairly good job of this, but most other examples I've seen don't. – Charles Staats Mar 09 '14 at 18:11
  • 2
    @JosephWright http://tex.stackexchange.com/questions/152890/backward-definition-of-latex-commands – Torbjørn T. Mar 09 '14 at 18:12
  • @Torbjørn: Thanks for the reference! As far as I can tell, my question is an exact duplicate, so I'm voting to close it as such. – Charles Staats Mar 09 '14 at 18:20
  • 1
    For whatever it is worth, I always get confused when things are backwards as in your examples. (To me, they are backwards!) So I define things forwards whenever I can. If I think it non-obvious why I'm doing it, I add a comment. (I guess this is a bit like saying 'to be proved' -> proof -> qed or abstract/outline -> argument -> conclusion.) However, the example in the duplicate question I do not think is backwards! – cfr Mar 10 '14 at 03:13

0 Answers0