# C style compilation of tex document

Would it be possible to implement a C style compilation model for tex documents? That is

latex -S file_1.tex file_2.tex file_3.tex #produce some kind of object files with "Undefined references"
latexlink -o repor.dvi file_1.txo file_2.txo file_3.txo #Link the chapters (put the data in that order)


This would have the benefit of creating scope for preambles so providing a MWE would be much easier. The idea is that the "object files" will not contain any macros that can infer with other stuff, and these "txo" files can be reused in other documents as well. Also it would improve compilation speed, since not the entire document needs to be recompiled.

• This is already there. It is called a format. – Henri Menke Nov 3 '15 at 8:30
• @HenriMenke Not really. Formats do much less than what the stage to "Undefined references" is. – yo' Nov 3 '15 at 8:31
• @yo' I can't think of a mechanism (that would actually work) to save already output pages in such a manner that they can be easily stacked together to a full document. Everything else, i.e. macros which can be reused across documents and do not depend on the document itself, can be realised with a format. – Henri Menke Nov 3 '15 at 8:34
• @HenriMenke But what if the macros depend on the way how the document is typeset? This can happen and does happen. – yo' Nov 3 '15 at 8:38

As an example, consider that you can have different section headers on even and odd page. This basically means that you have two internal macros -- \sectionodd and \sectioneven -- for the section, and you call the correct one depending on the parity of the page number. First, this itself is a two-compilation thing: you have to remember the page number from the previous compilation to get it right. Second, the user can define \sectionodd and \sectioneven in a very strange way, he can decide that one of them will change the basic macros of the engine etc. and since you can't predict this, you can't know for sure what's going on until you trully process the document with everything that should be there.
• In my opinion it's the box mechanism. What's inside a box can't be opened again ;-) – user31729 Nov 3 '15 at 8:39
• @ChristianHupfer hmmmm \unhbox ..... – David Carlisle Nov 3 '15 at 8:44
• @user877329 I think you do not understand it. I can do things like \ifnum\value{page}=146\relax \let\hbox\vbox\fi. If this code appears on page 146, it changes the definition of the macro \hbox to \vbox, which almost surely breaks LaTeX. If the code is elsewhere, nothing happens. Of course, this example is useless, but there are cases where you do things like this. To mention one: output routine changes, as performed e.g. by longtable. – yo' Nov 3 '15 at 8:47
• @user877329 But that means leaving everything to the linker, because based on the page breaking, you can redefine everything. In C, this is impossible, once you have a function called bla, it's bla. In TeX, even the meaning of the language's primitives can be changed (and it is commonly changed, LaTeX changes a good handful of them). You can't even do what Python allows, that is, to pre-parse the program, because the meaning of \\ and { etc. can be changed (and is commonly changed, e.g. in \verb), therefore the parser cannot be fixed to one syntax. – yo' Nov 3 '15 at 9:03