Design Concepts of the J% Programming Language (Revised Edition)

The idea

The 2015 chapter asked how domain-specific languages can be embedded in general-purpose ones efficiently, conceded that efficiency is hard to define, and then never defined it. The revision decomposes that into three questions the thesis can answer with evidence: whether embedded DSL programs can be validated at compile time and which classes of fault move there as a result; whether the data flowing across the language boundary can be made type-safe and relative to which assumptions; and whether a new DSL can be supported without modifying the host compiler, at what cost to the programmer who merely uses it.

What changed

• Informal claims are replaced by a stated module contract and a safety theorem. The 2015 text promised that exchanged values would be “proper” — a value-level property no static check can deliver — and that promise is withdrawn rather than restated.
• Requirements are written so a later chapter can check them, and each is traced to the design element that realises it.
• A new requirement on diagnostic attribution: every error reported against source the programmer actually wrote, every boundary failure identifying its responsible party. The chapter says plainly that this is where the design is weakest.
• An analysis of validation oracles — what “checked” means depends on the grammar or engine that defines well-formedness — and of the environmental oracles the original walked past.
• The extensibility claim is sharpened. J% is coupled to Java, so host-independence was never the differentiator; module-pluggability at low buy-in cost is.

Every change is itemised in the chapter's own §3.8, and notes marked [Retrospective] flag the places where it reasons about systems built after 2015.

Where it sits

The compiler it was revised alongside is J%; the original chapter is part of the 2015 thesis.