Article URL: https://www.humprog.org/~stephen/blog/research/recovering-abstraction.html Comments URL: https://news.ycombinator.com/item?id=49110624 Points: 6 # Comments: 0

Computer science in general, and language implementation in particular, are founded on the idea of realising abstractions in a way I'll call “forwards” and also “existential”. This post is about how these aren't the only way to think about programming infrastructure and abstractions. The theory goes that you pick some desired abstraction—it could be a programming language, maybe an abstract data type, or something else. Then you figure out the realisation. In the case of a programming language, this could be memory layouts, calling conventions and a compiler that generates object code modelling these. For abstract data types, it's some specific concrete data structure and the mapping from abstract to concrete operations. That's the “forwards” part. It's also “existential” when you keep the details of the realisation to yourself. Client code (e.g. source code in our new language) knows there is a realisation but the implementation choices themselves are hidden. In turn this allows the implementer to change their minds, while having indemnified themselves against any fallout when this breaks things. (Cynical, me?) So far, so textbook. However, this hiding isn't always done. Examples of “opting out” of hiding are ABIs and debuggers. ABIs opt out of hiding in favour of a public convention: certain implementation choices are documented publicly, while also being embodied in code. This allows independent implementations to interoperate. (It's a pity ABIs aren't often defined in some more machine-readable, declarative form.) DWARF-style debugging, meanwhile, as I've written about before, opts out of hiding by instead operating at the meta-level. Debuggers consume machine-readable descriptions of the implementation details, generated by compilers. Again, like ABIs, this is motivated by something about independent implementations working together (but... wait). The ABI example has simply dropped the existential quantification and left us with something we could call “propositional” i.e. a single, elaborated set of implementation decisions. But the debugger's approach goes further. It is the opposite of existential. It is a “universal” program! It consumes a description of how to view the concrete, abstractly. In principle it can recover the abstract view of any concretion, within some domain of discourse. It's universal, not existential.