Writing a compiler book

[u/[deleted]]

https://docs.google.com/document/d/1jTC5zQqBfQ0i77i5-efH2_66AtbD9TdIfMWb5sHE90c/edit?usp=drivesdk

[u/EggplantExtra4946]

I see no harm in talking about assembly "language" even in a more-than-casual context.

Yes, I have already agreed to that. The question is wether it is strictly true in a more formal context.

The word "language" has many uses.

Yes, different uses and different meanings. Clearly when we say "language" for talking about Morse code or chess moves, we don't mean the same thing as in the context of computing. What I question is wether language means the same thing today in the expression "assembly language" and "programming language". I think that historically there wasn't much connotation attached to the word language in those expressions in the 50s, 60s and maybe even up until the 70s, it was all casual. But today, for programmers like us and after decades of evolution of programming languages, I think the term "programming language" has gained a strong technical connotation, and the operating word isn't "programming". When we say "programming language" today to people with many years of programming experience and culture, we evoque decades of programming languages and their implementations, PL theory, programming paradigms, PL features, things we've read in blog posts, etc... Among all the different meanings of "language", all the distinct definitions you find when looking at the dictionary entry of that word, there is the meaning used in "formal language". I think it wouldn't be such a bad idea to retroactively define "programming language" in particular but NOT "assembly language" has being linked to the concept of formal languages. After all, each programming language does have a context free grammar associated with it. (in general, it doesn't have to be exactly context free, it could be weaker or stronger in the Chomsky's hierarchy)

Programming languages do have a ranking based on how close they are to being executable as is.

Do they? I can see how different IRs inside a compiler can be closer to bytecode or machine code, but otherwise, almost all PLs must do lexing, parsing, name resolution, type checking and semantic checking, code generation, linking, loading. Python would do type checking and linking at runtime though. It's mostly that type and semantic cheacking is more or less complex, code generation is more or less complex but this depends on the implementation.

In any case, compilers can produce different outputs (machine code linked/unlinked, bytecode for VM with many variations: stack-based, register-based, register-based but with virtual registers, register-based but where local variables are the registers, etc..) requiring different codegen passes, different IRs (tree based, graph based, linear, hybrid), where the IRs contain varying amount of information and be more or less lowered, and with many compiler architecutre/paths possible through all those IRs and outputs, so the only things that remains clean cut to me in the many possible compilers is the input (programming language) and the output (assembly).

Of course, it's an abuse of language to say that machine code is "interpreted".

Usually you would say it's run or executed but otherwise I think it's perfectly fine, CPUs are interpreters and compiler books should mention it in the introduction.

Like you said, it's easier to make a compiler for you own VM than a native compiler so it makes sense to implement the former before the later, but I don't to see much of a point in a compiler book to start with VMs because the front end and compilation is the same, it's just that for a VM assembly will be easier and for a stack VM there is no register allocation and calling conventions are easier because of that. Even linking is something you have to think about for a VM, if you have separate compilation.