You are analyzing the React Compiler's HIR (High-level Intermediate Representation) type system and construction. This is research only -- do NOT edit any files.
The goal is to produce a structured analysis document that will help us adapt these concepts for CloudLang, an OCaml compiler that decomposes TypeScript closures into Cloudflare Workers.
Files to read and analyze (all under /home/jm/data/ai/cloudlang-trees/react/react/compiler/packages/babel-plugin-react-compiler/src/):
HIR/HIR.ts- Core type definitions (this is ~1700+ lines, read it thoroughly in chunks)HIR/Types.ts- Type system typesHIR/ObjectShape.ts- Function signature / shape systemHIR/BuildHIR.ts- AST -> HIR loweringHIR/HIRBuilder.ts- HIR construction helpersHIR/visitors.ts- HIR traversal utilitiesHIR/PrintHIR.ts- Debug printing (useful for understanding structure)
Also read the existing CloudLang types for comparison:
/home/jm/data/ai/cloudlang-trees/react/lib/ast.ml- Current AST (19 node types)/home/jm/data/ai/cloudlang-trees/react/lib/ir.ml- Current IR (Cloudflare config)
For each major component, produce documentation in this template format:
# Component Name
## File
## Purpose
## Input Invariants
## Output Guarantees
## Algorithm (detailed, step-by-step)
## Key Data Structures (with type signatures)
## Edge Cases
## Mapping to CloudLang
- What we'd adapt and how
- What we'd skip and why
- OCaml type sketches for the adapted versions
## Example (before/after transformation)
Specific questions to answer:
HIR Core Model: What are Place, Identifier, Instruction, InstructionValue, Terminal, BasicBlock, HIR, HIRFunction? How do they relate? Draw the ownership/containment hierarchy.
Identity System: How are BlockId, InstructionId, IdentifierId, ScopeId generated and used? Why branded/opaque types?
InstructionValue variants: List ALL ~40 variants. For each, note: (a) is it relevant to CloudLang's TypeScript subset? (b) what data does it carry? (c) what are its effects/semantics? Group them by category (loads, stores, expressions, control flow, etc.)
Terminal variants: List ALL ~20 variants. Same treatment.
The Place/Identifier distinction: Why separate Place from Identifier? What does
effect,reactive,mutableRange,scopeon these types buy you?BuildHIR lowering: How does it convert Babel AST nodes to HIR instructions? What's the approach for handling control flow (if/else, loops, try/catch)? How are scopes and variables handled?
Type System (Types.ts): What types exist? How does the shape system work (ObjectShape.ts)? How do shapes encode function signatures?
Visitor patterns (visitors.ts): What traversal abstractions exist? How do passes consume the HIR?
CloudLang context: CloudLang currently has a flat ESTree AST (19 node types, no position info) and a Cloudflare-config IR. There's no proper HIR between them. The scope analysis works directly on the AST. We want to design an HIR that:
- Represents TypeScript constructs relevant to closure/mutation analysis
- Is extensible (start with current 19 node types, grow incrementally)
- Supports SSA, effect annotation, mutable ranges
- Can be implemented in OCaml with algebraic data types
Return your complete analysis as a single structured markdown document. Be thorough -- this is the foundational data model everything else depends on.