August 26, 2024 Languages Without Abstraction have stuff like a "control-flow graph" or "SSA form." Some kinds of analyses and transformations are easier in more abstract representations that have thrown away certain information. But those aren't good for all purposes.
For example: we generally need a syntax tree that very directly corresponds to whatever it is the user wrote: we don't really have the liberty to change it too much. This is because if we're going to complain that the types in their program are wrong, we need to explain it to them in a way that makes sense to them with the context they have, which is precisely the program they wrote, not how we'd prefer to represent what they wrote in some more abstract form. So we travel down the ladder of abstraction, moving our program further and further away from something recognizable as what the user gave us, into increasingly abstract representations closer and closer to how a computer would prefer to think about a program.
For example, the pipeline might look like this. Sometimes we'll have more than one IR (intermediate representation) if different IRs are good for different purposes. In short, we throw away information.
Stuff like: the comments in the file, the names that a user gave a variable, which are liable to be replaced with some kind of opaque identifier, the parenthesization of an expression, which will become unnecessary as the barbarous, textual string is replaced with an unambiguous, blessed tree, the fact that a given function was once generic, as we substitute in concrete type values and monomorphize it. I've been thinking lately about languages that, by necessity, do not have the luxury of abstraction in their representation. Consider the LLVM IR.
Here's an excerpt from the introduction: The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time...
NULL BITMAP by Justin Jaffray.
