Hacker News Reader

Comment by ketralnis | Hacker News Reader

I don't think that's either important or correct.

The biggest distinction I'd make between an interpreter and compiler is whether you need it to be present at execution time†, and if you use TeX to output PDF then obviously you don't need TeX to be present to view the PDF.

Correctness aside here's what you're replying to:

> TeX is the macro language and the compiler, LaTeX is the library.

What exactly here makes any compiler/interpreter distinction important? How is the communication improved by this "important" "distinction"?

†: Yes yes there are so many nitpicky "corrections" to make here that, indeed, any "distinction" can approach meaninglessness. If you're about to reply with that, read the second bit.

View on HN

> What exactly here makes any compiler/interpreter distinction important?

In my book, a compiler is an algorithm that (if implemented correctly) terminates for every input. An interpreter (of a Turing-complete language) will obviously occasionally not terminate. This distinction is very important when composing software.

Your distinction has the flaw that you assume that "execution" happens only once, while it is perfectly reasonable for an interpreted program to yield another program.

Your comment seems unreasonably aggressive.

The PDF isn't a program; it's a graphics file. You can't execute it, only view part or all of it. That's true of DVI too (see https://www.mn.uio.no/ifi/tjenester/it/hjelp/latex/dvi.pdf ); although it's easy to get confused by the terminology of "operators" and "commands", neither PDF nor DVI includes things like flow control or subroutines. (PDF does permit embedding things like JS, ICC profiles, and TrueType fonts, all of which permit significantly greater computational expressivity, but none of the relevant subformats can be output by LaTeX or TeX. DVI has none of this.)

LaTeX runs in the TeX interpreter, not in the PDF or DVI file. If TeX were a compiler, LaTeX and similar libraries would be present in TeX's output file, and would execute when that output file was used. If you had a runtime error in LaTeX, it would be logged when you tried to view the PDF or DVI file, and things like LaTeX's layout decisions might depend on the PDF or DVI viewer. Because TeX is an interpreter, not a compiler, execution time is when you run TeX, and LaTeX and similar libraries run when you run TeX, and they produce the output file. They are not present in the output file even when the output file is in a Turing-complete language like PostScript.

It is entirely possible to do your text reflow and layout in PostScript, which is how it would work if TeX were compiling your source file and its libraries into PostScript, but that is not how TeX works, because TeX is an interpreter, not a compiler.

It is important to understand this distinction because it bears on questions like what kinds of output files TeX can generate, when and where you get error messages from LaTeX, and what kinds of incompatibilities you may have to troubleshoot when you are using TeX.

>If TeX were a compiler, LaTeX and similar libraries would be present in TeX's output file.

Would it? If I compile a statically linked program, I can't see any c, or any of the libraries used in it.

If you can't see the libraries in the statically linked program, you aren't looking very hard. The linker copies library functions into the statically linked program, fixing up relocations. This is easiest to see if you compile with debugging enabled, because objdump -d will list the symbol names. Otherwise you may have to resort to looking for instruction sequences or, with LTO, even dataflow graphs.

It's true that there isn't any C in the output of the C compiler, but that's because C is the language your input program is written in; it isn't the program itself.

I kind of want to see a result with the objective of having (La)TeX documents to be easily editable without having to re-run the entire (La)TeX stack over and over again. I think we share this objective as something positive. Like having WordPerfect 5.1 with reveal codes being LaTeX, and real-time rendering of the document.

But your nitpick about if it is a compiler or an interpreter is irrelevant IMO.

You want some persistent runtime as the solution to having a more responsive TeX workflow. And think compiler vs interpreter is the answer.

I will argue is the total opposite. A compiler would produce an end result, in this case a plain document. An interpreter will have the runtime inside, as all interpreters do. Therefore, the interpreter is the right solution. What we need is an interpreter that stays in memory, with all its memory structures representing the TeX data, and that updates the memory structures when we type text.

The fact that when TeX runs it reads a file, then process its instructions and then terminates, is an argument to classify it as a compiler. An interpreter gives us a prompt and awaits for orders.

I haven't talked at all about whether incremental WYSIWYG editing of TeX documents is desirable, nor indeed about incremental WYSIWYG editing of TeX documents at all. Nor did I talk about whether a more responsive TeX workflow was desirable. The only things I said were desirable were (a) being less aggressive and (b) understanding the distinction between interpreters and compilers.

I have no idea why you would believe I agree with you about these objectives. Perhaps you have me confused with somebody else, in addition to being confused about what a compiler is, and about whether TeX has an interactive mode with a prompt, which it does (as, you point out, do many other interpreters).

Your proposed definition of "compiler", which would make grep a "compiler", as well as CPython when run with a .py file as an argument, but not HotSpot, is almost completely unrelated to the standard definitions. I have quoted a selection of them for your edification in https://news.ycombinator.com/item?id=32362579. The standard term for what you are calling a "compiler" is "batch-mode program".

> I haven't talked at all about whether incremental WYSIWYG editing of TeX documents is desirable, nor indeed about incremental WYSIWYG editing of TeX documents at all. Nor did I talk about whether a more responsive TeX workflow was desirable.

In that case, I find this conversation irrelevant to me. The precise definitions are just that, definitions, and are there to serve an objective, they are not the end themselves. Goodbye.

> The PDF isn't a program; it's a graphics file. You can't execute it

PDFs and their viewers[1] can do much[2] more than people think.

1. https://twitter.com/LinguaBrowse/status/1057937468564140033

2. https://opensource.adobe.com/dc-acrobat-sdk-docs/

Because I'm working on a DARPA research program where we are sanitizing PDF files, this is addressed at the end of the paragraph you were quoting; you might have considered reading to the end of the second paragraph of my comment before replying:

> (PDF does permit embedding things like JS, ICC profiles, and TrueType fonts, all of which permit significantly greater computational expressivity, but none of the relevant subformats can be output by LaTeX or TeX. DVI has none of this.)

Reply on news.ycombinator.com