Microsoft Intentional Compiler Replaces Source Text With Tree Enzymes

dftube

Separating programming intentions from executable implementations allows transformation enzymes to modernize code and synthesize interfaces without modifying original source files.

AI-assisted summary of Intentional Programming demo (Part 2) - Compiler — original source. Check the original for full context.

Source published: 2006-08-25

Key ideas

Intentional Programming treats source code as a database instead of raw text, enabling programmatic transformation tools called 'enzymes' to manipulate structures like extracting procedures with minimal boilerplate. (0:08)
To prevent compile-time collisions between independently authored enzymes, IP enforces monotonic tree growth where additions are permitted but deletions are strictly prohibited. (2:00)
Legacy C++ ingestion recovers intent from textual preprocessor macros by converting implicit scope dependencies and loop bodies into explicit, structured intention parameters. (4:28)
In a Java UI case study, over 50% of application code consisting of boilerplate event wiring is eliminated by annotating domain state as user-controlled and letting enzymes synthesize the interface. (7:15)

Detailed notes

## Background Published on YouTube by the channel dftube on August 25, 2006, this clip is the second part of an archival demonstration of a Microsoft research system called Intentional Programming. The uploader's description explains that the original footage was chopped into two ten-minute segments for YouTube to illustrate an unconventional way of working with code, focusing here on the compiler mechanics.

## TL;DR The video outlines the compiler architecture of Intentional Programming (IP), a paradigm that treats source code as a database of structured intentions rather than raw text. Transformations are executed by modular tools called 'enzymes,' which resolve compile-time ordering through stylized semantic queries while adhering to a strict rule allowing tree additions but forbidding deletions. The presentation also shows how IP converts implicit legacy C++ preprocessor macros into explicit, parameterized abstractions. Finally, a Java painting applet demonstrates how declarative domain intentions eliminate extensive UI boilerplate by automatically generating and upgrading interface widgets directly from underlying transformation enzymes.

## Atmosphere & style The presentation carries the methodical, cerebral atmosphere of a late-1990s corporate research lecture, complete with calm narration and measured technical exposition. The tone is deeply earnest and visionary, pairing biological metaphors like 'enzymes' and 'ecologies' with practical architectural walkthroughs and dry humor about the limits of automation. It feels like an authentic artifact from an alternate trajectory of software engineering, methodically dismantling traditional text-based programming in favor of elegant structural graphs.

## Bulletin - [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) Intentional Programming treats source code as a database instead of raw text, enabling programmatic transformation tools called 'enzymes' to manipulate structures like extracting procedures with minimal boilerplate. - [02:00](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=120s) To prevent compile-time collisions between independently authored enzymes, IP enforces monotonic tree growth where additions are permitted but deletions are strictly prohibited. - [04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) Legacy C++ ingestion recovers intent from textual preprocessor macros by converting implicit scope dependencies and loop bodies into explicit, structured intention parameters. - [07:15](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=435s) In a Java UI case study, over 50% of application code consisting of boilerplate event wiring is eliminated by annotating domain state as user-controlled and letting enzymes synthesize the interface.

## Key takeaways - [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) Programs are modeled as structured databases rather than textual source files, making code transformation tools straightforward to build. - [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) Transformation tools called 'enzymes' can perform complex structural refactorings, such as lifting inline code into parameterized procedures across just a few pages of code. - [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) Every intention in the tree requires distinct attributes: an identity, visual rendering specifications, editing behavior, and transformation reduction rules. - [02:00](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=120s) Intentions collaborate across the tree by emitting stylized semantic queries called 'questions' (e.g., querying types or constant values) rather than scraping intermediate raw tree nodes. - [02:00](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=120s) Higher-level constructs lower themselves by delegating generic questions to simpler primitives while intercepting construct-specific behaviors like jump targets. - [02:00](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=120s) Compile-time tree stability is maintained by a strict rule allowing node additions while strictly forbidding node deletions. - [02:00](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=120s) Dependency tracking schedules observer operations strictly after modifiers, guaranteeing deterministic lowering across independently authored transformations. - [04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) Generic operations decouple abstract archetype declarations from concrete implementations, allowing distributed third-party specializations without altering core definitions. - [04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) Legacy source ingestion runs an intention-recovery algorithm on C preprocessor macros to retain design abstractions instead of parsing flattened macro expansions. - [04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) Hidden scope couplings and unclosed loop bodies inside C macros are transformed into explicit, inspectable parameters upon ingestion into IP. - [07:15](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=435s) Traditional imperative UI programming incurs heavy boilerplate overhead, where over half of a Java applet's code is devoted strictly to widget plumbing and event handlers. - [07:15](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=435s) Marking domain variables and methods with declarative user-control intentions allows enzymes to synthesize UI widgets directly from underlying data types. - [07:15](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=435s) Separating domain intention from UI implementation allows developers to upgrade underlying widget controls across an entire application without modifying domain source code.

## Detailed walkthrough ### [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) Enzymes and the Ecology for New Abstractions

In the Intentional Programming (IP) paradigm, source code is treated fundamentally as a database rather than raw text. Because of this structured representation, creating tools that operate on programs becomes straightforward. Adopting biological metaphors, the developers refer to these code-manipulating tools as “enzymes.” A prime example demonstrated in IP is an enzyme designed to extract a procedure out of raw, open code: a programmer selects a block of code deemed sharable, triggers the enzyme, and IP instantly generates a separate procedure along with the corresponding call site, correctly piping through both formal and actual parameters. The narrator jokes about the limits of automation, noting, “It's too bad that the system cannot come up automatically with a meaningful name so we have to supply that.” Despite the complex manipulation taking place under the hood, writing such tools is relatively compact; using IP’s application programming interfaces (APIs) and domain-specific abstractions, the “lift procedures” enzyme spans only a few pages of code.

```mermaid flowchart LR accTitle: Lift Procedure Enzyme Workflow accDescr: Diagram showing how an enzyme extracts inline code into a reusable procedure with parameters. subgraph Input["Programmer Action"] A["Select Open Code in Tree"] end subgraph Enzyme["Enzyme Transformation"] B["Lift Procedure Enzyme"] end subgraph Output["Generated Artifacts"] C["New Extracted Procedure"] D["Call Site with Actual/Formal Parameters"] end A --> B B --> C B --> D ```

This structural tree foundation establishes an “ecology for new abstractions,” enabling any arbitrary abstraction to be plugged into the environment and leveraged immediately. Within IP, the term “intention” serves interchangeably to denote an abstraction, a programming language feature, or a distinct definition node in the tree. To give an intention life, a developer assigns it an identity and specifies how it should render visually, how it edits, and how it reduces down to an implementation via transformation enzymes. Intentions interact cooperatively via parameters. For instance, an `if` statement naturally treats its conditional test and the nested branch statements as its parameters. Virtually any intention can accept parameters or become a parameter itself, leaving it up to individual intentions to decide which combinations make semantic sense.

- **Program as database**: Eliminates manual text re-parsing, allowing programmatic enzymes to restructure code directly. - **Lift procedures enzyme**: Automatically extracts code blocks, binds all actual and formal parameters, and leaves naming to the developer. - **Intention attributes**: Every intention requires an identity, rendering/display rules, editing behaviors, and implementation transformation rules.

---

[02:00](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=120s) Collaboration, Semantic Questions, and Transformation Rules

Scaling an ecosystem where independently authored transformation enzymes operate over the same source tree introduces a hard technical challenge: preventing transformations from colliding and invalidating each other's work while lowering code into executable targets. Paul steps in to explain how IP resolves compile-time ordering. Because nodes must contribute to the build pipeline without prior passes corrupting later decisions, IP strictly orchestrates the execution order. Nodes avoid querying the raw global tree indiscriminately; instead, a node can directly inspect only its own internal structure. To discover external context, it emits stylized semantic queries to neighboring nodes called “questions.”

```mermaid flowchart TD accTitle: Compile-Time Node Collaboration via Semantic Questions accDescr: Shows how an intention node queries its neighbors using semantic questions and reduces down to implementations. subgraph NodeContext["Intention Node Querying"] N["Node (e.g., While Loop)"] Q1["Question: What is your type?"] Q2["Question: Do you have a constant value?"] Q3["Question: What is your reduced tree?"] end subgraph Resolution["Target Execution"] T["Delegate to Sub-Intentions (If / Goto)"] I["Intercept Local Questions (Break / Jump Target)"] end N --> Q1 N --> Q2 N --> Q3 Q3 --> T N --> I ```

Questions inquire about semantic invariants that stay stable even as the underlying tree transforms, such as: *“What is your type?”*, *“Do you have a constant value?”*, and crucially, *“What is the lower level tree, the reduced tree that constitutes your implementation?”* When an intention lowers itself, it can delegate unhandled questions to subordinate structures. For example, a `while` loop lowering into `if` and `goto` primitives passes basic conditional handling down to the `if` node, saving the author of `while` redundant logic, while intercepting loop-specific questions like where an inner `break` statement should branch. To maintain total consistency, IP enforces an immutable transformation law:

> “A strict rule for Transformations is that additions to the tree are allowed but deletions are not.”

If nodes were deleted arbitrarily, IP could never consistently determine whether an observer should perceive a node. Consequently, observers are scheduled strictly after modifiers through comprehensive internal dependency trackers. While IP cannot magically make conflicting program semantics compatible, it guarantees early detection and error reporting whenever semantic queries clash.

- **Semantic queries over tree scraping**: Isolates nodes from unstable structural intermediate states. - **Delegation and interception**: Higher-level constructs offload common semantics to basic control primitives (e.g., `while` deferring to `if`/`goto`) while retaining construct-specific intercepts (e.g., loop exit jumps). - **Monotonic tree growth**: Nodes may only be added during transformation passes, never removed, guaranteeing stable observation windows.

---

[04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) Generics, Archetypes, and Legacy C++ Ingestion

The power of intentional identity becomes particularly stark when dealing with generic operations where one conceptual operator maps to multiple concrete implementations. In conventional systems, dispatch logic is implicit. The narrator underscores that “making explicit what used to be implicit is typical to IP.” An intentional generic operator points directly to an “archetype declaration” that embodies the abstract operation and aggregates common attributes across variations. Because archetypes often reside in immutable standard libraries, IP allows specialized implementations to be contributed remotely rather than declared inline alongside the archetype. During compilation, the system gathers all distributed specializations and resolves the exact instance needed for each call site.

Beyond greenfield code, IP provides paths for legacy modernization. Front ends parse languages like C++, Java, or HTML directly into intentional trees. However, C++ preprocessor directives pose a severe hurdle: simply running the preprocessor and parsing the macro-expanded output strips critical architectural intent and abstractions. To solve this, IP uses an intention-recovery algorithm that reconstructs preprocessor directives into explicit intentional structures. In an illustrated C macro example, an unparameterized macro call hides an implicit dependence on a local variable in the calling scope, alongside an unclosed loop body. When imported into IP, the macro definition and call site are automatically rebuilt with two explicit parameters: one exposing the previously hidden local variable reference, and another explicitly wrapping the loop body. Instead of brittle textual injection, IP exposes latent coupling, turning invisible side effects into structured, safe abstractions while handling `#ifdef` directives, includes, and token concatenations cleanly.

- **Archetypes and specializations**: Decouples the abstract operator contract from implementation variants, allowing third-party libraries to provide new specializations without altering core definitions. - **Preprocessor recovery**: Extracts textual `#define` macros into clean, parameterized intentions without discarding program semantics. - **Defect surfacing**: Implicit scope intrusions in C macros are converted into visible, formal parameters that developers can review and refactor.

---

[07:15](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=435s) Declarative Domain Abstractions: Java UI Case Study

To showcase how domain-specific abstractions outshine general procedural code, the demonstration pivots to a classic graphical user interface (GUI) problem: a simple Java painting applet where users pick colors, draw with a mouse, and clear the screen. Examining the original Java source reveals a familiar defect: over half of the application text consists strictly of boilerplate UI scaffolding (highlighted in red) rather than domain graphics logic. From the domain perspective, the user interface is merely incidental plumbing to alter pen colors or trigger a canvas reset.

The demonstration shifts into the IP environment:

```mermaid flowchart LR accTitle: Declarative Domain Abstraction Transformation accDescr: Contrast between manual Java imperative UI wiring and IP declarative attribute transformation. subgraph LegacyJava["Java Imperative Model"] direction TB J1["25+ Lines of UI Wiring per Field"] J2["Manual ActionListeners & Event Loops"] J1 -.->|"High Bug Potential"| J2 end subgraph IntentionalModel["IP Declarative Model"] direction TB I1["Mark State/Method as User Controlled"] I2["Transformation Enzyme Generates UI Widgets"] I3["Enzyme Update Automatically Adds ColorPicker"] I1 --> I2 --> I3 end ```

In IP, the presenter strips out all GUI plumbing, leaving only the pure domain logic. The variable representing pen color and the procedure clearing the canvas are simply annotated with an intention marking them as under user control. An underlying UI transformation enzyme inspects these annotations and automatically synthesizes the user interface, generating a drop-down selector derived directly from the variable’s enumerated type. When a new color parameter is added to the `clear` procedure, the interface updates itself instantly. In raw Java, making that identical change requires manually authoring 25 lines of event-handling and widget-wiring code, “any one of which could have been the cause of a bug.”

Furthermore, because implementations are detached from intentions, updating the UI transformation enzyme instantly improves the application without touching the programmer's domain code. When an updated enzyme incorporating a full visual ColorPicker component is loaded, the applet adopts the advanced control automatically. Contrasting this paradigm with traditional imperative development, the presenter explains:

> “By separating the intention from the implementation, improvements in the implementations become accessible to the programmers without having to change the program source.”

- **Boilerplate elimination**: Imperative UI code comprising over 50% of the Java file is replaced by declarative intention markers directly on domain logic. - **Automated type-to-widget derivation**: Enumerated types automatically synthesize corresponding UI selectors (e.g., drop-down menus or ColorPickers). - **Maintenance velocity**: Avoids error-prone manual updates (such as the 25 lines of Java required to bind a single parameter change) by delegating code lowering to reusable enzymes.

## Notable quotes > [07:15](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=435s) By separating the intention from the implementation, improvements in the implementations become accessible to the programmers without having to change the program source.

> [02:00](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=120s) A strict rule for Transformations is that additions to the tree are allowed but deletions are not. — Paul

## Mentioned Intentional Programming, Microsoft, Paul, C++, Java, HTML, ColorPicker

## Video description An old research system from Microsoft, video off the net chopped up to fit into two 10 minute clips for youtube, interesting way to work with code.

Un vieja sistema de la investigación de los putos de Microsoft, vídeo en inglés de la Internet tajó hasta ajuste en dos partes de diez minutitos para el youtube, una manera interesante de trabajar con código.

This one doesn't make much sense but check out the other clip about the editor, which is pretty cool.

Eso video no es muy claro, pero fija el otro video, es genial, guey.

[Source](https://www.youtube.com/watch?v=ZZDwB4-DPXE)

中文简报

微软意图编译器以树酶替代源代码文本将编程意图与可执行实现相分离，使转换酶能够在不修改原始源文件的情况下实现代码现代化并合成接口。该视频概述了意图编程（IP）的编译器架构，这种范式将源代码视为结构化意图的数据库，而非原始文本。转换操作由称为“酶”的模块化工具执行，这些工具通过程式化的语义查询来确定编译时顺序，同时严格遵守只允许添加树节点但禁止删除的规则。演讲还展示了意图编程如何将遗留的隐式 C++ 预处理器宏转换为显式的参数化抽象。最后，一个 Java 绘图小应用程序展示了声明式领域意图如何通过直接利用底层转换酶自动生成和升级界面控件，从而消除大量 UI 样板代码。意图编程将源代码视为数据库而非原始文本，使名为“酶”的程序化转换工具能够以极少的样板代码操作结构（如提取过程）。 (0:08) 为防止独立编写的酶之间发生编译时冲突，意图编程强制实行树的单调递增，即允许添加但严格禁止删除。 (2:00) 遗留 C++ 代码摄取通过将隐式作用域依赖和循环体转换为显式、结构化的意图参数，从文本预处理器宏中恢复意图。 (4:28) 在 Java UI 案例研究中，通过将领域状态标注为用户受控并由酶来合成界面，消除了占应用程序代码 50% 以上的样板事件绑定。 (7:15)

Reading summary

The Intentional Programming (IP) paradigm treats software source code as an extensible database rather than raw text, allowing transformation enzymes to lower high-level domain abstractions into executable code while preserving architectural intent. Treating Programs as Databases via Transformation Enzymes (0:08) In conventional software engineering, source code is managed as flat text, necessitating continuous re-parsing. Intentional Programming instead represents software as an underlying tree-structured database of nodes called "intentions," which represent domain abstractions, language constructs, or distinct definitions. Developers manipulate these trees using modular tools termed "enzymes." For instance, the demonstrated "lift procedures" enzyme inspects user-selected inline code, extracts it into a separate procedure, and generates the call site with proper actual and formal parameter bindings, leaving only the procedure name for the developer to specify. Every intention possesses an identity, visual display rendering rules, editing behaviors, and transformation rules for reduction into lower-level code. Intentions collaborate through parameters—much like an conditional construct taking test conditions and branch bodies as parameters—allowing arbitrary language features to be plugged into the environment and combined based on semantic validity. Coordinating Transformations via Semantic Invariants and Monotonicity (2:00) Running independent transformation enzymes over a shared source tree risks compilation conflicts and phase ordering issues. To coordinate node lowering safely, IP restricts nodes from indiscriminately inspecting global tree syntax. Instead, an intention node inspects only its internal structure and queries neighboring nodes using standardized semantic "questions" about invariants that persist across transformations, such as asking for a node's type, constant value, or reduced implementation tree. Lower-level generation relies on delegation and interception. For example, a while-loop lowering into lower-level primitives offloads branch conditions down to an if-node while intercepting loop-specific break targets. To maintain consistency across observing nodes, IP enforces a strict monotonic rule: transformations may add nodes to the tree, but deletions are prohibited. Internal dependency trackers ensure observers are scheduled strictly after modifiers, surfacing early diagnostic errors whenever conflicting semantics arise. Explicit Archetypes and Legacy C++ Macro Ingestion (4:28) Intentional Programming emphasizes making implicit relationships explicit. For generic operations, an intentional operator references an "archetype declaration" representing the generalized contract. Specialized implementations do not need to be declared inline alongside the archetype; third-party libraries can contribute them remotely. The IP compiler then collects these distributed specializations to resolve the exact implementation required at each call site. This structured representation also enables the modernization of legacy codebases in languages like C++, Java, and HTML. Rather than expanding textual preprocessor macros—which strips away architectural structure—IP utilizes an intention-recovery algorithm that converts macros, token concatenations, and conditional directives into explicit, parameterized intentions. If a legacy C macro relies on implicit local variables in the caller's scope or leaves loop bodies open, the recovery system exposes the hidden coupling by generating visible formal parameters and wrapped blocks. Decoupling Domain Logic from Imperative UI Boilerplate (7:15) The practical advantage of domain-specific intentions is demonstrated through a comparison with a standard Java graphics applet. In the traditional Java implementation, over half of the source text consists of imperative UI scaffolding, including event listeners and widget wiring, rather than drawing logic. Adding a single parameter to a method in raw Java required manually authoring roughly 25 lines of event-handling and widget-binding code, which the presenter notes introduces opportunities for bugs. Under IP, the programmer marks domain elements—such as pen color state and canvas-clearing procedures—with an intention declaring them under user control. An underlying UI transformation enzyme inspects these annotations and automatically synthesizes the appropriate interface elements based on data types, such as creating drop-down menus from enumerations. Because intentions remain decoupled from implementation logic, upgrading the UI transformation enzyme to generate an advanced visual color picker improves the application interface automatically without requiring modifications to the underlying domain code. By replacing textual manipulation with structured database transformations, semantic queries, and explicit archetypes, Intentional Programming demonstrates how domain logic can be maintained independently from platform-specific implementation plumbing.

精炼阅读摘要

意图编程（Intentional Programming，简称 IP）将源代码视为结构化数据库而非纯文本，通过解耦抽象意图与具体实现，利用酶（Enzyme）转换工具自动化代码重构与界面生成，从而消除样板代码并降低编译与维护复杂度。程序即数据库与酶转换机制 (0:08) 在意图编程范式中，源代码从根本上被当作数据库处理，而非无结构的纯文本。这种树状结构表示使得对程序进行操作的工具开发变得极为精简。演示中将这些操作代码的工具比喻为“酶”（Enzymes）。例如，用于从现有代码中提取复用过程的“提升过程酶”（Lift Procedures Enzyme），只需开发者圈选代码并触发，系统便会自动生成独立过程及其调用点，并自动绑定形参与实参，开发者仅需补充过程名称。尽管底层树结构变换极其复杂，但在 IP 的 API 与领域抽象支持下，该工具的实现代码仅占数页纸。这种结构树基础构建了所谓的“新抽象生态系统”，允许任何意图（Intention）自由接入。在 IP 中，“意图”可代指抽象、语言特性或语法树中的独立定义节点。每个意图都具备唯一标识符，并需定义其视觉渲染方式、编辑交互行为以及通过酶将其降解为具体实现的转换规则。意图之间通过参数协同运作，例如 if 语句将条件表达式和分支代码块视作自身参数，各意图可自主判定特定参数组合是否具有语义意义。语义提问与单调递增转换法则 (2:00) 当多个由不同开发者编写的转换酶在同一语法树上并发操作时，IP 必须解决编译期转换顺序与协同冲突的问题。系统严格编排节点的执行顺序，禁止节点随意爬取全局树结构；相反，每个节点仅能检查自身内部结构，并通过向邻近节点发出标准化的“语义提问”（Questions）来获知外部上下文。这些提问涵盖在树变换过程中保持不变的语义不变量，例如询问邻近节点的类型、是否为常量，或者其降解后的底层实现树结构。当高阶意图向下转换时，可以将未处理的问题委派给下层原语，同时拦截特定问题。例如 while 循环降解为 if 和 goto 时，可将常规条件分支逻辑委托给 if 节点，同时自身拦截针对内部 break 语句的跳转目标查询。为保证编译期观测的一致性，IP 确立了严格的转换准则：转换过程中仅允许向树中添加节点，绝对禁止删除节点。通过这一单调递增约束与内置依赖跟踪机制，系统确保观察者节点总是在修改者节点之后执行，并在语义查询发生冲突时能够尽早报错。泛型原型与旧代码意图恢复 (4:28) 在泛型操作处理上，传统编译器往往隐式分发代码，而 IP 的核心原则是将隐式逻辑显式化。泛型操作符直接指向一个“原型声明”（Archetype Declaration），该原型代表抽象操作并聚合共有属性。由于原型常位于不可修改的标准库中，IP 允许第三方库以分布式方式远程提交具体特化实现，在编译期间系统再根据调用点具体参数收集并解析对应的特化版本。针对 C++、Java 等遗留代码的前端导入，IP 采用意图恢复算法处理棘手的宏定义问题。传统的 C 预处理器会直接展开宏，抹除架构意图并引入隐式依赖。IP 的恢复算法能将 C 语言宏重构为显式的参数化意图。演示案例展示了一个表面上无参数的 C 宏，其实际上隐式依赖了调用作用域内的局部变量且包含未闭合循环体；导入 IP 后，该宏被自动重构为带有两个显式参数的意图，清晰暴露出原先隐藏的局部变量引用与循环代码块，从而将脆弱的文本替换转化为结构化、安全的抽象表示。声明式领域抽象消除界面样板 (7:15) 以一个经典的 Java 绘图 Applet 为例，传统面向对象实现中超过一半的代码均为用于监听事件和装配界面的样板代码（如颜色选择与画板重置逻辑），而真正的领域绘图代码占比极小。若按照传统命令式开发，仅为画板清除操作增加一个颜色参数，就需要手动修改约 25 行事件处理与控件组装代码，极易引入潜在缺陷。在 IP 环境中，开发者可以剥离全部界面样板代码，仅保留核心领域逻辑。表示画笔颜色的变量及清屏过程只需标注声明式意图，指明其受用户控制即可。底层的 UI 转换酶会自动扫描这些属性，并依据变量的枚举类型直接合成对应的下拉选单控件。更重要的是，由于意图与实现完全解耦，当转换酶升级引入更复杂的视觉取色器组件时，应用程序源代码无需做任何改动，即可自动获得更先进的用户界面交互功能。意图编程通过将代码结构化并把抽象意图与降解实现严格分离，证明了自动化消除样板代码和安全现代化遗留代码的可行性；然而，该演示主要展示了语法与界面层面的降解，对于极其复杂的跨模块语义冲突，系统虽能尽早捕获报错，但依然无法自动调和不兼容的程序语义。

Detailed notes — zh

## Background 该视频由 YouTube 频道 dftube 于 2006 年 8 月 25 日发布。简介指出，这是来自微软研究院的一套古老研究系统演示录像，原视频被拆分为两段 10 分钟的片段上传，展示了一种颠覆传统的代码交互与编程范式。 ## TL;DR 本期演示深入剖析了意向编程（Intentional Programming, IP）的编译器架构与元编程理念。系统将程序视为结构化数据库，利用名为“酶”的转换工具对语法树进行代码重构与单调扩展，并通过精密的语义提问机制解决跨抽象协同与编译调度冲突。此外，演示还展示了 IP 如何逆向还原 C++ 宏中的隐式依赖，以及如何通过领域特定抽象（DSA）将冗长的 Java UI 胶水代码精简为纯粹声明式的业务标记。 ## Atmosphere & style 整段演示洋溢着 90 年代末至千禧年初计算机前沿研究所特有的纯粹黑客极客气质，节奏沉稳扎实且充满智力密集的学术推演。主讲人与工程师 Paul 的配合严丝合缝，语气冷静而笃定，偶尔穿插对早期原型局限的幽默调侃。看着一行行繁琐的传统代码被瞬时解构为优雅的语义树，观众既能感受到底层编译理论的严谨秩序感，又能体会到前瞻性软件工程构想所带来的震撼与超前感。 ## Bulletin - [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) 意向编程（IP）将代码视作结构化数据库而非扁平文本，通过被称为“酶”的元编程工具集直接在代码树上执行函数提取与重构。 - [01:58](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=118s) 编译器采用单调变换原则，规定树节点在转换时只允许追加、绝不允许删除，并借助标准化语义提问机制解决跨酶协作与依赖冲突。 - [04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) IP 支持对 C++ 宏等旧代码进行意图逆向恢复，将隐式局部变量捕获与控制流代码块显式转化为具名参数，保留代码不变量。 - [07:14](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=434s) 在领域特定抽象下，IP 能够将 Java 传统绘图程序中占比超过一半的 UI 胶水代码完全抹除，仅凭轻量意图标记自动推导交互界面。 ## Key takeaways - [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) 程序在 IP 中被视为结构化数据库，这使得开发元编程与代码分析工具的门槛大幅降低。 - [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) “酶”（Enzymes）是操作代码树的元编程实体，例如“提取过程酶”可在极短实现篇幅下自动推导形式参数与实际参数。 - [01:05](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=65s) “意图”（Intention）统括了语言特性与代码树节点，由全局唯一标识、可视化外观和底层实现三要素构成。 - [01:30](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=90s) 语言语法结构被完全泛化为意图与参数，任意意图之间只要语义合理便可自由组合与嵌套。 - [01:58](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=118s) 编译期多酶协同依赖于严格的节点局部性约束，节点通过向相邻节点发起标准化的“语义提问”来感知全局语境。 - [03:30](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=210s) IP 转换遵循单调变换铁律：代码树只允许追加节点而严禁删除节点，借此规避观察者与修改者之间的竞态冲突。 - [04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) 泛型操作符被抽象为“原型声明”（Archetype），其特化实现可物理分离并在编译期间由系统自动汇聚匹配。 - [05:15](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=315s) IP 摒弃了传统的文本预处理器展开，而是通过逆向恢复算法将 C++ 宏重构为结构良好、参数显式化的意图节点。 - [07:14](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=434s) 传统过程式代码（如 Java Applet）往往充斥着大量用于维护 UI 控件的模板胶水代码，掩盖了纯粹的业务算法。 - [08:05](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=485s) 借助 UI 转换酶，开发者仅需在数据字段和方法上添加意图标记，系统即可全自动推导出下拉菜单与触发按钮等界面组件。 - [09:10](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=550s) 声明式意图表达将“想要什么”与“如何实现”彻底解耦，使底层架构与控件升级能够无感惠及业务代码，终结频繁重构源码的困局。 ## Detailed walkthrough ### [00:08](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=8s) 程序即数据库：酶（Enzymes）与抽象生态系统在意向编程（Intentional Programming, 简称 IP）的体系构想中，程序本质上是一个结构化的数据库，而非单纯扁平的文本文件。正是基于这种数据结构特性，开发者能够极为轻松地构建出各类用于分析、修改和重构程序的工具。系统开发者借鉴了生化领域的概念，将这些操作代码树的工具形象地命名为“酶”（Enzymes）。演讲者在演示中展示了一个非常实用的重构酶：它可以直接从一段开放式代码中提取出独立的子过程。用户只需选中一段具有复用价值的代码，直接施加该酶，系统便能瞬间生成一个新的过程定义以及对应的调用语句，并自动推导并补全所有形式参数（Formal Parameters）和实际参数（Actual Parameters）。演讲者稍带遗憾地调侃道，系统目前还无法凭空猜测出符合业务语境的变量命名，因此程序员仍需手动输入有意义的名称；但编写这类酶本身非常轻松，依托 IP 提供的丰富 API 和领域特定抽象，“提取过程酶”（Lift Procedures Enzyme）的核心实现代码仅仅只有几页纸的篇幅。 IP 这种基于语法树（Tree Representation）的底层架构，其核心价值在于催生出了一个自我演进的“抽象生态系统”。在这个生态中，无论是何种形式的崭新抽象，都可以随时注入系统并立即投入使用。因为这些抽象承载并直接表达了程序员的计算意图，IP 体系内索性将“抽象”、“编程语言特性”以及“代码树中的定义节点”统称为“意图”（Intention）。要让一个意图生效并具备实用价值，系统要求开发者为其赋予唯一标识（Identity），并定义它的外观呈现方式、底层实现逻辑以及编辑交互规则。意图与意图之间能够通过参数无缝协作，例如一个典型的 `if` 条件语句，其判断条件和下辖的分支执行体本质上就是它的参数。在 IP 的通用哲学里，任何意图都可以拥有参数，任何意图也都可以成为其他意图的参数，它们之间的组合完全由各自的语义合理性来决定；而意图的底层实现，正是通过类似于交互编辑酶的“转换酶”（Transformation Enzyme）来进行形式转化的。 - **酶的核心功能**：提供面向程序树的元编程工具集，例如“提取过程酶”可自动化解析变量作用域并完成函数封装与参数传递。 - **意图（Intention）的三要素**：拥有全局唯一标识（Identity）、定义可视化的渲染呈现外观（Look）、具备可执行或可降解的代码实现（Implementation）。 - **参数组合的通用原则**：语法结构中的分支与表达式被统一泛化为意图与参数，支持任意意图之间的互为嵌套与协作。 --- ### [01:58](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=118s) 编译期协同、提问机制（Questions）与单调变换当多个由不同开发者独立编写的代码转换酶汇聚到同一棵源代码树上工作时，如何确保它们能够协同运作并输出确定且合理的结果，构成了编译器设计中最严苛的技术瓶颈。协助讲解的工程师 Paul 深入剖析了这一机制的解法：在编译期，程序中的所有意图节点必须通力协作，一步步构建出最终的目标代码。这意味着树上的各个节点必须遵循某种既定秩序贡献自己的转换逻辑，而这一调度次序完全由 IP 编译器自主判定。该调度逻辑的底层铁律在于：任何意图已经采集到的上下文语义信息，在后续的编译步骤中绝不能被其他互不相关的意图破坏或篡改。 ```mermaid flowchart TD accTitle: IP编译期节点提问与委托机制 accDescr: 展示节点如何通过语义提问和向下委托来实现转换协同 subgraph TreeContext ["语法树上下文协同"] NodeA["上层意图节点 (如 While)"] NodeB["底层意图实现 (如 If / Goto)"] end subgraph SemanticQuery ["语义提问机制 (Questions)"] Q1["“你的数据类型是什么？”"] Q2["“你是否拥有常量折叠值？”"] Q3["“构成你实现的归约子树是什么？”"] end NodeA -->|"直接自身查询"| NodeA NodeA -->|"发起样式化提问"| SemanticQuery SemanticQuery -->|"委托或拦截"| NodeB ``` 为了确保 IP 能够迅速推导出不引发语义失效的执行队列，API 施加了严格的局部性约束：每个节点在默认状态下仅允许探查自身的直接结构；若要理解其在树中的全局语境，它必须向相邻节点发起规范化的“提问”（Questions）。这类提问具有强烈的语义稳定性，因为即便代码树在编译转换中形态剧烈改变，节点的本质语义依然恒定。常见的提问包括“你的类型是什么？”、“你是否具有常量值？”，以及最为核心的——“构成你底层实现的归约树（Reduced Tree）是什么？”。通过这种抽象提问，节点既能隐藏自身细节，又能与外围结构紧密协作。例如一个 `while` 循环在利用 `if` 和 `goto` 落地自身实现时，可以直接将条件求值问题向下“委托”给 `if` 节点处理，而自身仅需拦截诸如“跳出当前循环的目标跳转位置”这一类核心问题。为了消除观察者与修改者之间的竞态冲突，编译转换遵循极其严苛的操作准则，正如 Paul 所强调的： > “A strict rule for Transformations is that additions to the tree are allowed but deletions are not.”（转换操作遵循一条极其严苛的规则：只允许向树中追加节点，绝不允许删除节点。）如果节点能够被任意新增与移除，IP 系统便根本无法断定何时向观察者汇报节点的存在状态。因此系统默认所有新追加的内容必须对查找它们的意图立即可见，这意味着观察者必须严格在修改者之后执行。系统维护着庞大的依赖追踪图谱来强行约束这一执行顺序；即便 IP 无法预先拍胸脯保证任意两组孤立意图必定兼容，它也能够精准捕捉冲突并报错，通过精心设计的语义提问体系，促成复合抽象在逻辑自洽的前提下高度协同。 --- ### [04:28](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=268s) 泛型原型机制与旧代码的意图恢复（C++ 宏重构）在单一定义的操作符场景下，意图标识（Intentional Identity）的优势一目了然，但当面对重载与泛型（Generics）——即同一个操作存在多种不同定义时，IP 的展现机制更为独特。IP 的标志性特征便是将过去代码中隐晦含糊的概念显式化。一个泛型操作符节点在树中直接指向一个被称为“原型声明”（Archetype Declaration）的核心实体，该实体代表了这项抽象操作的规范概括，也是提炼各类具体特化形态共性的理想载体。针对该泛型过程的具体特化实现（Specializations）则作为外围贡献挂载至原型之下。由于原型定义通常深居于受权限保护的标准类库之中无法直接改动，IP 允许特化实现与原型物理分离，由系统在编译期间自动汇聚各个贡献分支，并为每一处泛型调用精准匹配最合适的分派实例。面对 C++、Java 或 HTML 等传统代码（Legacy Code），IP 同样展现了降维兼容能力：其语法元素完全可以被映射并定义为 IP 树内部的意图。通过改造标准编译器的前端词法语法分析器，系统可以直接解析源代码文本并构造成意图树。然而在处理 C++ 复杂的预处理器宏命令（Preprocessor Directives）时，传统的编译解法面临严峻考验： > “It would not be a good idea to Simply parse the output of the pre-processor into an IP tree because valuable information would be lost.”（如果仅仅将预处理器的输出结果直接解析为 IP 树，那绝不是个好主意，因为这样会丢失极其宝贵的语义信息。）为了完整保留宏定义所代表的代码不变量（Invariants），IP 研发了一套精密的逆向恢复算法，能将文本级的宏逻辑升格为结构化的意图体系。演示展示了一个典型案例：原 C 代码中包含一个无参宏，并在某处调用。将该代码导入 IP 后，原本看似无需传参的宏调用在转化后自动浮现出两个崭新的参数： 1. **隐式局部变量暴露**：原宏内部玩弄了语法隐蔽引用，通过硬编码的名称直接绑定了调用现场作用域内的局部变量（在不同调用点绑定的实际变量各不相同），IP 将这种危险的上下文变量捕获显式重构为一个传入参数。 2. **控制流代码块捕获**：原宏借助不闭合的代码结构悄悄吞掉了调用处后续的循环体代码，IP 将这部分被暗中裹挟的循环体识别为第二个代码块参数。通过这种“意图恢复”，IP 不仅在摒弃文本级预处理器机制的同时完整复刻了原有逻辑，更将旧代码中丑陋、隐蔽且脆弱的依赖关系大白于天下，使其成为易于排查和重构的高质量 AST 结构。同样的处理逻辑也被平移运用到了 `#ifdef` 条件编译、文件包含（`#include`）以及宏词法拼接符号的处理上。 --- ### [07:14](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=434s) 领域特定抽象与声明式 GUI 构建在脱离了通用编程语言语法的束缚后，意图编程在领域特定抽象（Domain Specific Abstractions, DSA）上展现了更巨大的威力，其中典型的落地场景便是图形用户界面（UI）。演讲者以一段用传统 Java 编写的绘图小程序（Applet）为例：该程序提供基础的画板功能，允许用户切换画笔颜色、用鼠标绘制草图以及一键清空画布。然而代码层面的现实却十分荒诞——在原程序的全部代码量中，超过一半的代码行数通篇只是为了搭建和维系最基本的 UI 交互控件（在演示中被整体标红高亮）。从软件架构核心来看，绘图程序的主旨仅仅在于执行绘图算法本身；所谓的 UI 界面，本质上不过是一种允许外部用户更改类成员变量（如当前画笔颜色）或触发特定方法（如清空画布方法）的桥接魔法而已。理想的工程状态理应将此类界面交互部件与核心绘图逻辑彻底解耦。借助 IP，演讲者展示了一场极具颠覆性的代码瘦身演示： ```mermaid flowchart LR accTitle: 意图驱动声明式UI生成 accDescr: 展示从领域意图标记直接自动推导出交互界面的转换过程 subgraph UserDomain ["开发者意图声明"] CleanCode["纯净绘图业务逻辑"] IntentionMark["意图标记 (@UserControl)"] CleanCode --- IntentionMark end subgraph TransformationEnzyme ["UI 转换酶自动推导"] Parser["类型与方法探测器"] Parser -->|"探测枚举类型"| Dropdown["自动生成下拉选择框"] Parser -->|"探测无参/带参方法"| ActionBtn["自动生成带参触发按钮"] end subgraph RenderedUI ["最终生成运行界面"] ColorSelect["颜色选取下拉列表"] ClearBtn["附带颜色选择器的清空按钮"] end IntentionMark --> TransformationEnzyme Dropdown --> ColorSelect ActionBtn --> ClearBtn ``` 在 IP 编辑器中，开发者直接将所有冗杂的 Java 界面交互代码整块抹除，仅仅在需要开放给用户操作的颜色变量声明以及清空函数声明上方打上一个轻量的“意图标记”（Mark）。系统内部的 UI 转换酶随即接管后续工作： - 识别到颜色变量绑定了枚举类型时，转换酶全自动推导出下拉列表框并呈现出可选颜色。 - 当开发者为清空方法额外增加一个“底色颜色”参数时，界面呈现结构实时同步响应，无需编写一行胶水代码；而在传统 Java 源代码中，实现这一看似细微的界面联动至少需要手动编写或改动 25 行零碎代码，且每行都有引入并发或监听 bug 的风险。 - 当底层的意图引擎实现迭代升级时（例如引入了更先进的弹出式调色板 `ColorPicker`），所有依赖该意图的项目只需加载一次意图更新，其界面便全自动享受到高级调色板能力，而底层的核心源代码一字未改。演说的尾声揭示了两种编程范式的本质分野：Java 属于典型的过程式（Procedural）语言，其语句重在详尽阐述计算机每一步“该如何做”（How to do things）；与之相对，IP 所倡导的领域特定抽象则是高度声明式（Declarative）的，聚焦于精准表达业务“想要什么”（What should be done）。声明式代码兼具简短凝练与多重落地可能，通过将纯粹的意图与千变万化的底层实现完全剥离，底层的算法与架构改进得以无感且透明地惠及每一位程序员，彻底终结了为了底层细节而频繁翻新业务源码的软件工程困局。 ## Notable quotes > [01:58](https://www.youtube.com/watch?v=ZZDwB4-DPXE&t=118s) A strict rule for Transformations is that additions to the tree are allowed but deletions are not. — Paul ## Mentioned Intentional Programming, Microsoft, Paul, C++, Java, HTML ## Video description An old research system from Microsoft, video off the net chopped up to fit into two 10 minute clips for youtube, interesting way to work with code. Un vieja sistema de la investigación de los putos de Microsoft, vídeo en inglés de la Internet tajó hasta ajuste en dos partes de diez minutitos para el youtube, una manera interesante de trabajar con código. This one doesn't make much sense but check out the other clip about the editor, which is pretty cool. Eso video no es muy claro, pero fija el otro video, es genial, guey. [Source](https://www.youtube.com/watch?v=ZZDwB4-DPXE)

Source quotes

[1:58] Paul: A strict rule for Transformations is that additions to the tree are allowed but deletions are not.

Source quotes

[7:15] By separating the intention from the implementation, improvements in the implementations become accessible to the programmers without having to change the program source. [2:00] Paul: A strict rule for Transformations is that additions to the tree are allowed but deletions are not.

Original transcript

[0:08] given that the program is a database [0:10] it's easy to create tools that operate [0:12] on programs because we like biological [0:15] metaphors we call these tools enzymes [0:18] there is in IP a very useful enzyme that [0:21] can extract a procedure from open code [0:23] we start by selecting a piece of code [0:25] that we think might be [0:27] sharable we apply the enzyme and we get [0:30] a procedure and a call to it with all [0:32] the necessary parameters formal and [0:35] actual it's too bad that the system [0:37] cannot come up automatically with a [0:39] meaningful name so we have to supply [0:42] that writing a new enzyme is not very [0:46] hard using IP's powerful apis and domain [0:50] specific abstractions the lift [0:52] procedures enzyme is only a few pages [0:56] long the most important consequence of [0:59] the IP treat representation is to create [1:01] an ecology for new abstractions this [1:04] means that new abstractions of any kind [1:07] can be added to the system and used [1:09] right away because the abstractions are [1:11] used to express the programmer's [1:13] computational intent we frequently use [1:15] the word intention to mean an [1:17] abstraction a programming language [1:19] feature a definition in the IP [1:22] tree we recall that to make an intention [1:25] useful we need to provide it with an [1:27] identity then describe how it should [1:28] look how it might be be implemented [1:30] edited and so [1:32] on intentions can cooperate through [1:35] parameters for example an if statement [1:37] has its condition and the conditional [1:39] statement under it as its parameters in [1:41] principle any intention can have [1:43] parameters and any intention can be a [1:46] parameter it's up to the intentions to [1:48] decide what combinations make sense the [1:51] implementation of an intention is [1:53] described by a transformation enzyme [1:55] very much like the editing enzyme we saw [1:57] earlier let's now turn to a difficult [2:00] technical problem how can we create a [2:02] system where separately written [2:04] Transformations can come together [2:06] operate on the same Source tree and [2:08] produce a meaningful result Paul will [2:10] explain the [2:11] solution at compile time the intentions [2:14] in a program must collaborate to build [2:16] the desired Target the nodes in the tree [2:18] have to make their contributions to this [2:20] process in some order and that order [2:22] must be determined by IP it's essential [2:25] that information that any intention [2:27] acquires will not be invalidated later [2:28] by another independent intention so to [2:31] ensure the IP can quickly find an order [2:33] in which nothing is invalidated the API [2:35] allows an intention to ask for the [2:37] minimal information it needs a node can [2:40] directly examine only its own structure [2:43] in order to learn more about its context [2:45] in the tree it will make stylized [2:46] queries of other nodes connected to it [2:49] we call these queries [2:50] questions questions are semantic in [2:52] nature since the semantics of a node is [2:54] unlikely to change during the build even [2:56] as the tree structure is [2:58] transformed examp examples of questions [3:00] are what is your [3:04] type do you have a constant [3:08] value and most importantly what is the [3:11] lower level tree the reduced tree that [3:13] constitutes your [3:15] implementation these semantic questions [3:18] provide a means for portions of the tree [3:19] to be abstracted away yet still [3:21] cooperate with the surrounding [3:23] nodes when an intention expresses itself [3:26] in terms of other intentions it can [3:28] delegate questions to them [3:30] for example a while loop might choose to [3:32] implement itself in terms of ifs and [3:35] go-tos questions that the if can handle [3:37] are delegated to it saving the author of [3:40] while the trouble of handling them some [3:42] questions may still be intercepted by [3:44] while though for example a question [3:46] about where to jump in order to break [3:48] out of the [3:49] loop a strict rule for Transformations [3:52] is that additions to the tree are [3:54] allowed but deletions are not if nodes [3:56] could come and go in the tree it would [3:58] be impossible for IP to decide whether [3:59] to report the presence of a node to an [4:01] observer by convention all additions are [4:04] visible to intentions that look for them [4:06] which means that observers must run [4:08] after modifiers the system maintains [4:10] extensive dependency structures to [4:12] enforce this rule IP could not guarantee [4:15] that any two intentions will work [4:17] together but it can detect [4:19] incompatibilities and report an error [4:21] with carefully chosen questions it will [4:24] be possible for intentions to work [4:25] together when it is Meaningful to do so [4:28] the benefits of int IAL identity are [4:30] clear when for example there's only one [4:33] definition for an operator but in case [4:35] of generics when there are several [4:37] possible definitions for the same [4:38] operator the situation is even more [4:41] interesting making explicit what used to [4:43] be implicit is typical to IP a generic [4:46] operator points to an archetype [4:48] declaration that represents the abstract [4:50] operation this declaration is also a [4:53] convenient place to summarize what is [4:55] common among the diverse instances the [4:57] specializations of the generic procedure [5:00] will be contributed to the archetype [5:02] these specializations could appear next [5:04] to the archetype definition however the [5:06] archetype is frequently found in a [5:08] standard library that we cannot change [5:10] so we prefer to place the specialization [5:12] separate from the archetype the system [5:14] will collect the contributions and [5:16] select the appropriate instance for each [5:18] generic [5:20] reference we've seen how new programs [5:23] can be created and edited in IP but what [5:26] about Legacy code abstractions of a [5:29] Legacy language such as C++ can be [5:32] defined as intentions we can adapt a [5:34] standard compiler front end to parse C++ [5:37] text and create the intentional tree [5:40] this can be done for other languages as [5:41] well for example for [5:46] Java or for [5:49] HTML the pre-processor directives of C++ [5:52] create some interesting challenges it [5:55] would not be a good idea to Simply parse [5:56] the output of the pre-processor into an [5:58] IP tree because valuable information [6:01] would be lost what we would like is to [6:03] preserve the invariance represented by [6:05] the pre-processor directives and express [6:07] them intentionally this can be achieved [6:09] by a rather complex [6:12] algorithm the results of automatic [6:14] pre-processor intention recovery are [6:16] very interesting let's look at a typical [6:19] example here we see a macro definition [6:21] in the C source and a particular macro [6:24] call with no [6:26] parameters after import into IP we see [6:30] the automatically recovered macro [6:32] definition and the macro call note the [6:34] two new parameters in IP the first one [6:37] appears because the original macro [6:39] trickly referred by name to a local [6:41] variable in the Call's environment a [6:44] different variable in each [6:46] call the second parameter is the body of [6:48] the loop that has been picked up by the [6:50] sneaky syntax of the original [6:54] macro in this case IP did not just [6:57] Express the invariances of the original [6:59] tricky macro correctly and without [7:01] pre-processor actions but it also made [7:04] the undesirable dependency more visible [7:07] and correctable similar results exist [7:09] for if defs includes and name [7:13] concatenations we've seen that IP can [7:15] express abstractions from a wide variety [7:17] of languages from C preprocessors C++ [7:21] and other object-oriented languages but [7:23] even greater opportunities exist with [7:25] domain specific abstractions our example [7:28] comes from the common domain of user [7:30] interfaces this is an applet exercise [7:33] written in Java that implements a simple [7:35] paint program I can use the applet to [7:38] select a color draw with the mouse and [7:41] clear the canvas for a new [7:43] drawing the interesting point is that [7:46] more than half of the program text is [7:47] there to implement the user interface we [7:50] mark this portion in red the main goal [7:53] of the code is to paint of course from [7:56] that perspective the interface is just [7:57] some Magic by which the user sets class [8:00] variables such as the pen color or calls [8:03] some method such as the method for [8:04] clearing the canvas ideally the user [8:07] interface widgets that are used for this [8:09] purpose would be completely separated [8:11] from the part of the code that concerns [8:12] itself with [8:14] painting moving to IP let us delete all [8:17] the interface [8:21] code and mark the Declarations of the [8:23] variable and the procedure which we [8:26] think should be under user control [8:29] this Mark is an intention that can be [8:31] transformed to exactly the desired [8:40] interface note for example that the [8:42] transforming enzyme could automatically [8:45] create the drop-down list from the [8:46] enumerated type referenced in the [8:51] Declaration if we now add a new color [8:53] parameter to the clear procedure we see [8:56] that the interface will change [8:57] accordingly [9:07] incorporating the same change in the [9:09] original Java Source would have taken 25 [9:12] lines any one of which could have been [9:14] the cause of a [9:15] bug when intentions are improved all [9:18] users benefit for example just by [9:20] loading an update of the intention the [9:22] interface will be improved in this case [9:25] by the automatic incorporation of a [9:27] Color Picker [9:32] Java is a procedural language its [9:34] statements describe how to do things in [9:37] contrast many domain abstractions [9:39] including the one we've just used are [9:41] declarative they describe what should be [9:44] done they're better because they're [9:46] short and allow many ways of [9:48] accomplishing the intention by [9:50] separating the intention from the [9:52] implementation improvements in the [9:54] implementations become accessible to the [9:56] programmers without having to change the [9:58] program source