7 ms·

Important distinction: TeX is an interpreter, not a compiler.

by choeger 4y ago

code_biologist 4y ago
Why is that an important distinction? It's not clear to me that it is.
- kragen 4y ago
  See https://news.ycombinator.com/item?id=32350841 https://news.ycombinator.com/item?id=32350841.
- Shorel 4y ago
  It is not. And it is irrelevant, because the objective here is to produce good-looking documents, not to create or run programs.
  - choeger 4y ago
    It is. People get confused all the time when their "compilation" of a TeX "document" doesn't terminate or yields other typical runtime problems. LaTeX is a very leaky abstraction in that regard. For more than basic competence in using TeX, it is important to understand how it works internally and for that it is helpful to have an understanding of what an interpreter is.
    - Shorel 4y ago
      I disagree. I don't need to know the compiled opcodes of a Java program to know that I wrote code that tries to perform a division by zero. What I need is a clear explanation of the issue using the actual source code I wrote. That's it. Whatever does this job, a compiler, an interpreter, random fairies, quantum AI overlords, it is not relevant. Clear error messages that show my source code, and explain the issue, that's the answer to fix these typical runtime problems.
Koshkin 4y ago
Doesn’t TeX emit a file like a compiler? You could say that a PDF reader, say, is an “interpreter,” but TeX itself? I don’t think so.
- bonzini 4y ago
  A compiler generates a file that can be executed to produce the same computation performed by the original source. Since loops and conditionals(*) aren't apparent in TeX's output, but are performed entirely while TeX runs, it is an interpreter. Regarding the output, TeX is an interpreter that produces its output as a DVI or PDF file rather than as text on a console or showing it in a GUI. (*) Both those in the source, and those implicit in TeX's typesetting algorithm.
  - SkeuomorphicBee 4y ago
    You mentioned loops in the output as a requirement for a compiler, but I'm this case all compilers that unroll loops are not compilers. Early shader compilers come to mind.
    - kragen 4y ago
      I think it's a little fuzzier than that; compiled shaders can still take input, such as screen positions and uniforms and textures, and execute computations specified by your source program on that input. DVI files can't; they're just passive data, even if each page is described as "a series of commands". If your input language is a programming language, which TeX is, and the language processor chews on it and spits out some passive data, such as DVI or PDF, that language processor is an interpreter, not a compiler. A compiler translates an input program into a hopefully equivalent output program. By design, there is no way for a DVI file to be equivalent to a TeX file.
      - alexvoda 4y ago
        Is an XSLT processor a interpreter or a compiler? I think the terms are actually not that well defined and different people use different definitions. TeX is a compiler in the sense that it is a black box that takes input and transforms it into a different output. By this loose definition even a png to jpg converter is a "compiler". TeX is a interpreter in the sense that it takes code as input, executes it, and that computation just happens to produce data as output.
PaulDavisThe1st 4y ago
Some old sage: when you're relatively to new to computers, you don't understand the difference between an interpreter and a compiler. After a while, you see the difference, and it's substantial and important. After a while longer, you don't see the difference anymore, though for different reasons than at first.
- thrown_22 4y ago
  I once build an interpreter for x86_64 to see what my machine code was doing line by line. Then I read the GDB manual.
  - Joker_vD 4y ago
    A not-so-nice thing about GDB is that if you order it to disassemble a program with slightly unusual/wrong ELF headers, it (the GDB, not the program) can segfault which is quite an unreasonable thing for a debugger to do IMHO.
- lapinot 4y ago
  To make things a bit more clear (hope that's what you meant!): One concrete angle is that interpreters and compilers are usually intertwined: interpreters commonly have an abstract machine which is some language a bit simpler to execute than the full language, thus they have a compilation step at first. And compilers do stuff like constant propagation, inlining and other flavours of partial evaluation. Thus they contain some sorts of interpreters. Another more abstract angle is to consider interpreters as compilers into a "trivial" language consisting only of values and side effects or the flip side: considering compilers as interpreters with a non-standard semantic.
ketralnis 4y ago
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.
- kragen 4y ago
  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 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. See also https://news.ycombinator.com/item?id=32350924 https://news.ycombinator.com/item?id=32350924.

Important distinction: TeX is an interpreter, not a compiler.

code_biologist 4y ago

Why is that an important distinction? It's not clear to me that it is.

kragen 4y ago
See https://news.ycombinator.com/item?id=32350841 https://news.ycombinator.com/item?id=32350841.
Shorel 4y ago
It is not. And it is irrelevant, because the objective here is to produce good-looking documents, not to create or run programs.
- choeger 4y ago
  It is. People get confused all the time when their "compilation" of a TeX "document" doesn't terminate or yields other typical runtime problems. LaTeX is a very leaky abstraction in that regard. For more than basic competence in using TeX, it is important to understand how it works internally and for that it is helpful to have an understanding of what an interpreter is.
  - Shorel 4y ago
    I disagree. I don't need to know the compiled opcodes of a Java program to know that I wrote code that tries to perform a division by zero. What I need is a clear explanation of the issue using the actual source code I wrote. That's it. Whatever does this job, a compiler, an interpreter, random fairies, quantum AI overlords, it is not relevant. Clear error messages that show my source code, and explain the issue, that's the answer to fix these typical runtime problems.

Koshkin 4y ago

Doesn’t TeX emit a file like a compiler? You could say that a PDF reader, say, is an “interpreter,” but TeX itself? I don’t think so.

bonzini 4y ago
A compiler generates a file that can be executed to produce the same computation performed by the original source. Since loops and conditionals(*) aren't apparent in TeX's output, but are performed entirely while TeX runs, it is an interpreter. Regarding the output, TeX is an interpreter that produces its output as a DVI or PDF file rather than as text on a console or showing it in a GUI. (*) Both those in the source, and those implicit in TeX's typesetting algorithm.
- SkeuomorphicBee 4y ago
  You mentioned loops in the output as a requirement for a compiler, but I'm this case all compilers that unroll loops are not compilers. Early shader compilers come to mind.
  - kragen 4y ago
    I think it's a little fuzzier than that; compiled shaders can still take input, such as screen positions and uniforms and textures, and execute computations specified by your source program on that input. DVI files can't; they're just passive data, even if each page is described as "a series of commands". If your input language is a programming language, which TeX is, and the language processor chews on it and spits out some passive data, such as DVI or PDF, that language processor is an interpreter, not a compiler. A compiler translates an input program into a hopefully equivalent output program. By design, there is no way for a DVI file to be equivalent to a TeX file.
    - alexvoda 4y ago
      Is an XSLT processor a interpreter or a compiler? I think the terms are actually not that well defined and different people use different definitions. TeX is a compiler in the sense that it is a black box that takes input and transforms it into a different output. By this loose definition even a png to jpg converter is a "compiler". TeX is a interpreter in the sense that it takes code as input, executes it, and that computation just happens to produce data as output.

PaulDavisThe1st 4y ago

Some old sage: when you're relatively to new to computers, you don't understand the difference between an interpreter and a compiler. After a while, you see the difference, and it's substantial and important. After a while longer, you don't see the difference anymore, though for different reasons than at first.

thrown_22 4y ago
I once build an interpreter for x86_64 to see what my machine code was doing line by line. Then I read the GDB manual.
- Joker_vD 4y ago
  A not-so-nice thing about GDB is that if you order it to disassemble a program with slightly unusual/wrong ELF headers, it (the GDB, not the program) can segfault which is quite an unreasonable thing for a debugger to do IMHO.
lapinot 4y ago
To make things a bit more clear (hope that's what you meant!): One concrete angle is that interpreters and compilers are usually intertwined: interpreters commonly have an abstract machine which is some language a bit simpler to execute than the full language, thus they have a compilation step at first. And compilers do stuff like constant propagation, inlining and other flavours of partial evaluation. Thus they contain some sorts of interpreters. Another more abstract angle is to consider interpreters as compilers into a "trivial" language consisting only of values and side effects or the flip side: considering compilers as interpreters with a non-standard semantic.

ketralnis 4y ago

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.

kragen 4y ago
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 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. See also https://news.ycombinator.com/item?id=32350924 https://news.ycombinator.com/item?id=32350924.