{"id":"9f672c57-457d-43f2-8763-42723059e8f2","arxiv_id":"2509.09059","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A new intermediate language and compiler pass that preserves dependent types through memory allocation, using initialization flags on dependent pair types.","lead":"This paper designs a typed intermediate language that adds explicit memory allocation with initialization tracking to a dependently typed calculus, and sketches a compiler pass that allocates dependent pairs and closures while preserving types. It is a step toward a fully type-preserving compiler for dependently typed languages, which could prevent external code from breaking specifications during linking.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The theorem is under-specified: no translation for Π types is given, so Theorem 3.1 cannot be checked for closures; the substitution/conversion lemmas it depends on are unproved.","rationale":"The paper is an honest ongoing-work report, and the reader already marked it CONDITIONAL. Our stress-test finds one particularly load-bearing gap: the type translation for dependent function types is absent from Figure 2, yet Theorem 3.1 is stated for all types and the motivating application is closure conversion. This is not a proven fatal flaw, but it means the central claim cannot currently be checked. The unproved lemmas, especially substitution preservation, are also genuine gaps, but they are downstream of the missing Π translation. We agree partially with the reader: the reader listed the omitted Pi translation among several weaknesses; we identify it as the single most load-bearing one. A conditional verdict remains appropriate: the idea is plausible and the paper is transparent about its incompleteness, but the theorem as stated is not yet fully supported. We do not recommend rejection, because no internal inconsistency has been identified, and the missing definitions could plausibly be filled in. The concrete test would settle whether the omission is merely presentational or a real obstruction.","tokens_in":4013,"tokens_out":3974,"duration_ms":50863,"concrete_test":"Ask the authors to supply the complete type-translation equations, especially JΠ x:A.BK and JCode(...)K, and then verify the closure case of Theorem 3.1 on a minimal example: e = λ x:A.x at type Π x:A.A. Derive the target typing for the translation using the Figure 1 rules; if no JΠK definition exists, the theorem is vacuous for functions. Separately, test Lemma 3.5 with e = fst y and e' = ⟨a,b⟩ where y : Σ x:A 1.B 1; compute Je[e'/x]K and JeK[Je'K/x] and check whether they are convertible in CC-CC_A. If they are not, the [Snd] case of Theorem 3.1 breaks.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Theorem 3.1 quantifies over all source types A, and CC-CC includes dependent function types Π x:A.B, closure types, and code types. Yet Figure 2 defines the allocation translation for Σ types and for pair/closure terms, but gives no equation for JΠ x:A.BK, JCode(...)K, or the universes. The closure case in Figure 2 produces 'Clos y2', and the [Clo] rule types this only under a specific hypothesis about y2's fully-initialized Σ type; to conclude J⟨⟨e1,e2⟩⟩ as Π x:A.BK : JΠ x:A.BK one must know what JΠ x:A.BK is. Without that definition, the theorem's statement is incomplete for exactly the function/closures that the paper says the pass targets. Further, the proof of Theorem 3.1 relies on Lemmas 3.3–3.5, all stated without proof. Lemma 3.5 (substitution preservation) is especially load-bearing because dependent elimination like [Snd] substitutes a projected term into a type; with malloc and initialization flags, Je[e'/x]K and JeK[Je'K/x] could differ in allocation order, local let-bindings, and flag states. Lemma 3.4 (step preservation) also needs to show that allocation steps in the translated program match source reductions. The Section 4 consistency model is explicitly ongoing, so consistency of CC-CC_A is not established. This is not a demonstrated inconsistency, but the central claim is not yet supported by a checkable derivation.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents an ongoing design for a typed intermediate language CC-CC_A that adds explicit memory allocation and initialization to the dependently typed language CC-CC. The main contribution is a compiler pass, described in Figure 2, that translates dependent pairs and closures from CC-CC into CC-CC_A programs that allocate heap cells, initialize them, and (in the closure case) tag them as closures. The central claimed theorem (Theorem 3.1) states that this pass is type-preserving: if Γ ⊢ e : A in CC-CC, then ·; JΓK ⊢ JeK : JAK in CC-CC_A. The paper also sketches a consistency argument for CC-CC_A via a translation into extensional CIC. The proof of Theorem 3.1 is not supplied; it is asserted to follow by induction using Lemmas 3.2–3.5, which are also stated without proof. Section 4 explicitly notes that the eCIC model proof is still ongoing.","tokens_in":4455,"tokens_out":2129,"duration_ms":27221,"significance":"If completed, this work would provide a important building block for a fully dependently typed end-to-end compiler, addressing a real gap: linking trusted external code against erased specifications. The design of a dependent pair type with initialization flags, and the idea of treating closure allocation as heap initialization, are plausible and of interest to the PL/compiler community. The paper does not currently supply machine-checked proofs, complete definitions, or a verified consistency argument; its value is at the design/vision stage. The central theorem is not yet checkable because key definitions and lemmas are missing.","major_comments":[{"comment":"The allocation translation is defined only for Σ types, pairs, and closures. There is no equation for JΠ x:A.BK, JCode(...)K, or the universes. Since Theorem 3.1 quantifies over all source types A, and since the source calculus includes dependent function types and code types, the statement of the theorem is incomplete. In particular, the closure case in Figure 2 produces `Clos y2`, and its typing requires knowing JΠ x:A.BK to conclude that the translated term has the claimed type. The missing Π-type clause is load-bearing: without it, the closure case of Theorem 3.1 cannot even be stated, let alone proved.","section":"Section 2, Figure 2"},{"comment":"Lemmas 3.3, 3.4, and 3.5 are stated without proof. Lemma 3.5 (substitution preservation) is especially nontrivial and load-bearing: the translation introduces let-bindings, malloc, and initialization flags, so Je[e'/x]K and JeK[Je'K/x] may differ in allocation order, local let-bindings, and flag states. This lemma is required by the [Snd] rule and by the closure case of Theorem 3.1, where a term is substituted into a type. Lemma 3.4 also needs to account for the extra allocation and initialization steps in the translated program and for the heap (the conclusion mentions an arbitrary heap Ψ, but no typing rule for heaps is given). The assertion that these lemmas follow by 'straightforward induction' is not sufficient for a dependency-typed setting with a mutable heap.","section":"Section 3, Lemmas 3.3–3.5"},{"comment":"The consistency of the target language CC-CC_A is explicitly left as ongoing work. The paper claims that the eCIC model 'should be type-preserving' but does not provide the proof. Since a central motivation of the work is to ensure that linked external code cannot violate specifications, the type preservation theorem alone is insufficient: if CC-CC_A is inconsistent, then it could prove false, and the safety guarantee from typing would be vacuous. This is not a demonstrated flaw, but it is a missing load-bearing part of the overall claim.","section":"Section 4"},{"comment":"The theorem states `·; JΓK⊢ JeK : JAK`, but no definition of JΓK is given in Figure 2 or the surrounding text. Context translation is not trivial: variables now range over heap locations, and the context must account for the types of allocated pairs. The proof of the theorem cannot be checked without this definition. This is a small but necessary missing piece of the central statement.","section":"Section 3, Theorem 3.1"}],"minor_comments":[{"comment":"The [Clo] rule has a layout issue: the premise `e : Σ y:(Code(x1:A1, x:A).B) 1. A1^1` and the conclusion `Clos e : Π x:A[snd e/x1].B[snd e/x1]` are printed with unusual superscripts and spacing. These should be typeset more clearly, and the precise flag annotations should be explained.","section":"Section 2, Figure 1"},{"comment":"Typo: 'readibility' should be 'readability'.","section":"Section 4"},{"comment":"The paper says the typing/subtyping/conversion rules for CC-CC are 'the same as given by Bowman and Ahmed [3]' but does not reproduce them. Since CC-CC is not a standard calculus and the target rules depend on the source's conversion relation, a reader cannot verify the claims without consulting the external paper. A brief appendix recalling the source rules would improve self-containedness.","section":"Section 2"},{"comment":"The syntax of CC-CC_A is not given as a grammar; the text only mentions extensions. A formal syntax summary would help clarify the distinction between locations, heap values, and source expressions.","section":"Section 2, CC-CC_A syntax"}],"recommendation":"major_revision","confidential_remarks":"This submission is clearly labeled as ongoing work, and the missing proofs are explicitly acknowledged. As a referee, I would encourage the authors to complete the missing translations and lemmas; the current manuscript is a plausible extended abstract rather than a fully supported paper. There is no evidence of circularity or fabrication; the gaps are of completeness, not correctness. Given the venue expectations, major revision is appropriate rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The core idea here is sound and worth engaging with: take the initialization-flag trick from Morrisett et al., adapt it to dependent pair types, and use it for a type-preserving allocation pass on Bowman and Ahmed's CC-CC. That combination hasn't appeared before, and the motivating problem—checked linking against external code that could hand you uninitialized memory—is genuine. The translation in Figure 2 is clean: malloc, initialize components one at a time, tag closures. It reads like a natural next step in a longer dependent-type-preserving compiler project.\n\nThe paper is also honest about what is done and what is not. Section 4 explicitly says the eCIC model is ongoing, and the main theorem is presented as a proof sketch. That is the right framing for ongoing work.\n\nBut the stress-test is on target. Theorem 3.1 quantifies over all source types A, and CC-CC includes dependent functions and closure types, yet Figure 2 gives no translation for Π x:A.B, Code(...), or universes. The closure case literally produces a Clos tag, but without knowing what JΠ x:A.BK is, you cannot check the type preservation claim for closures—which is supposedly a central target of the pass. This is not a minor omission; it is the difference between a theorem statement and a precise one.\n\nAlso, the proof relies on Lemmas 3.3–3.5, all stated without proof. Lemma 3.5 (substitution preservation) is especially load-bearing: with heap allocation and flag changes, Je[e'/x]K should definitionally equal JeK[Je'K/x], but allocation order and local bindings could easily break that. The claim that everything follows by \"straightforward induction\" is too casual for this setting.\n\nTo be fair: I do not see a fatal flaw. The design is plausible, the prior work is cited appropriately, and the paper's own warnings align with my reading. The missing pieces are exactly what an extended abstract would defer, but they are too big for the theorem as stated to be verified.\n\nWho is this for? People working on type-preserving compilation for dependently typed languages. A workshop or a short-paper referee should look at it seriously; it will not be a full conference paper until the translation is completed and the lemmas are proved. I would bring it to a reading group, and I would cite it if I worked in this area. Recommendation: send to peer review, but expect revision or a more limited claim.","headline":"Sensible ongoing-work report with a real gap: the Pi/closure type translation is missing, so the main theorem is not checkable as stated.","tokens_in":4834,"tokens_out":1173,"would_cite":true,"duration_ms":15035,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A compiler pass allocates memory without erasing dependent types, so linked code can be checked against the original specification.","keywords":["dependent types","type-preserving compilation","memory allocation","initialization flags","closure conversion","typed intermediate language","linking","compiler correctness"],"falsifier":"Check whether the manuscript defines the translation for the dependent function type Πx:A.B and the code type Code(x:A,x':A').B. Figure 2 shows the translation of closure values but not of their types. If that clause is absent, Theorem 3.1 has no target type for any source program that uses a function, so the central claim as stated would collapse; a reader can decide this by looking for the omitted clause. As a second test, attempt the induction step of Lemma 3.5 for the case where the substituted variable appears in the type of a dependent pair; the translation introduces flag annotations th","tokens_in":3916,"feed_emoji":"💾","tokens_out":11556,"duration_ms":141633,"temperature":0.7,"pith_summary":"Most dependently typed languages erase specifications during compilation, so a later-linked C program can break them—for example, by passing an uninitialized pointer into the compiled code. The paper's proposal is to keep specifications alive by making memory allocation a typed operation rather than an untyped runtime effect. It defines a target language, CC-CC_A, whose dependent pair types carry initialization flags and which has explicit malloc and field-assignment operators. It then defines a translation from CC-CC and claims that every well-typed source term translates to a well-typed target term (Theorem 3.1). If the claim holds, this is a step toward a dependent-type-preserving compiler where link-time type checking can reject ill-typed external code.","feed_headline":"Compiler pass allocates memory without erasing dependent types","feed_subtitle":"Lets linkers reject external code that violates the original program's specifications.","key_machinery":"The mechanism that carries the argument is the initialization-flag dependent pair type, written 𝚺x:A^𝝓.B^𝝓' in the target language. The flags record whether each component of the pair has been initialized: malloc produces a pair with both flags 0, each field-assignment flips the corresponding flag, and projection rules require the flag to be 1. The translation J·K turns every source pair or closure value into a let-sequenced malloc followed by two field writes, so the resulting term's type itself records that both fields are initialized. This is what makes uninitialized-memory errors ill-typed rather than something to be caught at runtime.","core_discovery":"The paper's central claim is a translation J·K that compiles every source pair into an allocation sequence: allocate a two-word tuple, write both fields, and return the tuple with its type flags set to initialized; closures are allocated the same way then tagged as Clos. The target type system's key rule [Clo] lets a fully initialized allocated pair be used as a dependent function type. The paper states that this translation is type-preserving—the empty target context proves JΓK⊢JeK:JAK whenever Γ⊢e:A—and that this follows by straightforward induction from preserved subtyping, equivalence, conversion, and substitution lemmas. It also sketches a consistency argument for CC-CC_A by modelling i","pith_inferences":["The flag discipline is a lightweight form of permission tracking; one could generalize it to linear kinds and use it to type-check region-based memory management or a GC interface, a connection the paper does not draw.","The approach should transfer to any phase where initialization order matters—I/O buffers, GPU uploads, protocol serialisers—where dependent pair types with initialization flags could statically prevent use-before-write bugs.","A direct test would be to formalize Lemmas 3.2–3.5 in a proof assistant; the paper's 'straightforward induction' claim is not the same as a checked proof, and the omitted closure-type clause would force the formalizer to state it explicitly."],"forward_implications":["If correct, the pass lets compiler writers keep dependent specifications across allocation, so link-time type checking can prevent linking with code that violates memory-safety specifications.","The pass is designed to slot between existing typed CPS and closure-conversion passes, moving the compiler closer to a certified dependent-type-preserving pipeline to C.","The initialization flags make projections from uninitialized pairs statically impossible, eliminating a whole class of use-before-initialize bugs.","Completing the eCIC model would give a consistency proof for CC-CC_A, ensuring the target language cannot be used to prove false."],"fun_headline_variants":["Allocation pass keeps dependent types for linking","Dependent types survive memory allocation in new pass","Compiler pass preserves types to let linkers enforce specs","Memory allocation without erasing dependent types"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The theorem rests on the unstated conversion relation of the target language and on the unproved Lemma 3.5, that the allocation translation commutes with substitution on terms whose types mention dependent pairs; if either gives way, the type-preservation proof cannot be completed.","fun_headline_variants_meta":{"raw":{"variants":["Allocation pass keeps dependent types for linking","Dependent types survive memory allocation in new pass","Compiler pass preserves types to let linkers enforce specs","Memory allocation without erasing dependent types"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000143,"raw_usage":{"total_tokens":1016,"prompt_tokens":759,"completion_tokens":257,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":503,"completion_tokens_details":{"reasoning_tokens":200}},"tokens_in":503,"tokens_out":257,"duration_ms":3485,"temperature":1.0,"reasoning_tokens":200,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T19:44:12.871967+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Check whether the manuscript defines the translation for the dependent function type Πx:A.B and the code type Code(x:A,x':A').B. Figure 2 shows the translation of closure values but not of their types. If that clause is absent, Theorem 3.1 has no target type for any source program that uses a function, so the central claim as stated would collapse; a reader can decide this by looking for the omitted clause. As a second test, attempt the induction step of Lemma 3.5 for the case where the substituted variable appears in the type of a dependent pair; the translation introduces flag annotations th","supporting_citations":[],"review_version":1}