{"id":"daeacd89-c3eb-4ed8-8f3e-3139b7716857","arxiv_id":"2607.27074","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":7.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"Willow tracks render and event timing as graded effects, proves preservation, and uses the resulting temporal dependency graphs to statically detect cascades, loops, and stale listeners in React-like programs.","lead":"Willow is a core calculus and type-and-effect system that makes React-style render timing statically checkable. It turns buried runtime timing assumptions into effects and graphs that catch loops, cascades, and stale handlers before run time.","discovery_kind":"new_method","skeptic_critique":{"model":"grok-4.5","headline":"Preservation (Thm 6.1) only justifies one cascade step; multi-render loop/cascade detection rests on an unproven graph expansion plus a fidelity gap the paper does not close.","rationale":"The reader correctly flags the simplified semantics vs real React (no mount/unmount, no priority lanes, static labels) as the weakest assumption and lands on CONDITIONAL with low correctness risk for the definitional/proof core. I agree that is the main scope limit and do not move the verdict. The stress-test sharpens a closely related but distinct gap inside the strongest claim: Thm 6.1 is single-cascade preservation against the instrumented queue; the paper’s headline analyses are multi-render graph properties that are only informally tied to that theorem via full-effect expansion. That does not break the formal development within Willow, and the appendix proof is substantial pen-and-paper work with a working inference prototype on the paper’s examples, so correctness_risk stays low and CONDITIONAL remains right. No machine-checked proof; evaluation stays illustrative. I am not manufacturing a reject-level flaw—only noting that “preservation + graphs detect loops” is one theorem short of what the abstract claims, on top of the fidelity bound the reader already named.","tokens_in":57608,"tokens_out":728,"duration_ms":79849,"concrete_test":"State and prove (or refute) a multi-step corollary: if a well-typed configuration admits an infinite rendered→waiting→rendered sequence in the instrumented semantics, then the full-effect expansion of the initiating effect contains a loop[·] cycle. Separately, encode MutualRecursion and UsernameInput in React 18 with Strict Mode and concurrent features; compare observed update cycles/glitches to Willow’s expanded graph. Any React loop Willow misses, or Willow loop React batching eliminates, falsifies transfer of the detection claims.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The strongest claim conjoins Theorem 6.1 (preservation for instrumented configurations) with the assertion that expanded effects form temporal dependency graphs on which standard algorithms detect inter-render loops, render cascades, stale listeners, and related defects (§5.4; Abstract; Contributions). Preservation only guarantees that when a variable in X changes, a sub-effect of its Δ cascade appears in the next housekeeping queue under Willow’s two-phase, single-queue, no-mount semantics (Thm 6.1 / F.1; justify-on). The full-effect expansion that underwrites multi-render detection—recursive unfolding of ○, 2/3, ∗/+ over Δ with loop[·] markers (§5 “Immediate, cascading, and full effects”; §5.4)—is never stated as a corollary relating operational multi-render traces to cycles or paths in that graph, including across mixed units (r vs ms vs n) and + branches. Subcomponent reasoning is only α-renaming plus Δ_A ⊆ Δ (ty subcomp decl), and event labels are static base tuples. So even if Thm 6.1 is correct, the leap to “statically detect render cascades and inter-render loops” and to a “practical foundation” for React is carried by an informal expansion plus the fidelity assumption the paper itself flags (Conclusion: mount/unmount needs vertex structures; Related Work vs React-tRace). That is the load-bearing soft spot inside the central claim.","agreement_with_reader":"partial"},"referee_report":{"model":"grok-4.5","summary":"Willow is a React-inspired core calculus with a two-phase (render/housekeeping) operational semantics and a type-and-effect system that tracks state updates, event-handler lifecycle (bind/once/cancel/remove), and delays via a graded next modality ○ over host units (renders, ms, network). Effects inhabit an algebra with sequencing, branching, and event-guarded modalities; cascading effects live in an environment Δ and are expanded post-check into temporal dependency graphs on which the authors run standard graph algorithms for inter-render loops, render cascades, stale listeners, high-frequency handlers, and first-render cost. The paper proves preservation of effects w.r.t. an instrumented trace semantics (Theorem 6.1 / Appendix F), implements Hindley–Milner-style effect inference in Haskell, and evaluates on debounce, MovingDot, mutual recursion, and a signup-form case study that surfaces a stuck loading state, a request race, and a deliberate retry loop.","tokens_in":57940,"tokens_out":1405,"duration_ms":34285,"significance":"If the results hold at the stated scope, the work is a solid contribution to typed reactive programming: it makes render-relative and mixed-unit timing first-class in an effect system, unifies handler registration/teardown with state cascades, and shows that the resulting graphs support useful static warnings. Strengths include a detailed preservation development (configurations, declarations, expressions, queue typing, causes, subeffecting), a working inference prototype that checks every paper example, and a concrete case study that finds real timing bugs. The fidelity gap to full React (no mount/unmount, no concurrent lanes, static event labels) is acknowledged; within the simplified model the approach is a credible foundation for further work rather than an immediate drop-in React analyzer.","major_comments":[{"comment":"Abstract, Contributions, and §5.4 claim that inferred effects form temporal dependency graphs on which standard algorithms “statically detect” render cascades and inter-render loops. Theorem 6.1 / F.1 only guarantees that a change in X produces a sub-effect of the Δ cascade in the next housekeeping queue (justify-on). The multi-render full-effect expansion (recursive unfolding of ○, 2/3, ∗/+, loop[·] markers; §5 “Immediate, cascading, and full effects”) is never stated as a corollary relating operational multi-render traces to paths/cycles in that graph, including across mixed units (r vs ms vs n) and + branches. Either prove a soundness lemma for the expansion (over-approximation of multi-step traces) or clearly demote cascade/loop detection to a post-hoc heuristic justified only up to one cascade step plus informal graph reading.","section":"§5.4, Theorem 6.1 / Appendix F"},{"comment":"The central “practical foundation for … reactive programs” claim (Abstract; Conclusion) rests on a deliberately simplified semantics: immutable render phase, single event queue, no component mount/unmount, no React priority lanes or concurrent features, and only statically known event-label tuples (Conclusion; Related Work vs React-tRace). Subcomponent typing is α-renaming plus Δ_A ⊆ Δ (ty subcomp decl). These restrictions are load-bearing for transfer to real React; the paper flags mount/unmount as future dependent vertex structure work but still markets the analyses as catching defects “missed by compiler transformations and other current tools.” Scope the evaluation and claims explicitly to Willow’s model, and qualify every React-transfer sentence accordingly.","section":"Abstract; Conclusion; §4; ty subcomp decl"},{"comment":"Evaluation (§7) is a prototype inference run on hand-written patterns (debounce, MovingDot, mutual recursion, one signup form). There is no corpus study, no comparison against existing React linters/compilers, no false-positive/negative accounting, and no measurement of annotation burden beyond “minimal.” The signup-form findings are illuminating but anecdotal. For the claim that the system “statically finds and draws attention to timing bugs,” add at least a small structured case suite with expected warnings, or soften the empirical language to “feasibility demonstration.”","section":"§7"}],"minor_comments":[{"comment":"Notation for modalities is inconsistent across the text (○1𝑟 vs ○^{1r}, 2 vs □-like square, 7 vs remove glyph). Pick one rendering and stick to it in body, figures, and appendix.","section":"§2–§5"},{"comment":"Figure 1 syntax uses if 𝑥 then … (variable scrutinee) while expression typing/semantics allow general 𝑒1; align syntax and rules.","section":"Fig. 1; Fig. 7; Fig. 13"},{"comment":"df (dataflow function) is left as a parameter with “simplest instantiation = free variables.” State how the prototype instantiates df and whether imprecise df affects soundness of causes or only precision of cascades.","section":"§5"},{"comment":"Related work on FRP/modal FRP (Fran, Simply RaTT, ultrametric FRP) and graded monads is appropriate; a short explicit contrast table (what Willow tracks that React-tRace/λreact do not, and vice versa) would help readers.","section":"§8"},{"comment":"Typos and spacing: “Reactiveprogrammingframeworks”, “timing as-sumptionsburied”, “aprototypetype-and-effect”, “theseeffectscanbecomposed” suggest PDF generation issues; clean the camera-ready text.","section":"throughout"},{"comment":"Appendix F is long and useful; cross-reference key lemmas (Flush Queue Preservation, Listen typing inversion, expression listener-safety) from the main Theorem 6.1 statement so readers can navigate.","section":"§6; Appendix F"}],"recommendation":"major_revision","confidential_remarks":"The formal core looks carefully done and the prototype is a genuine plus; the main risk is over-claim relative to React. If the authors tighten the graph-expansion claim and scope language, this is a good PL venue paper. I do not see integrity or citation issues. Fit is appropriate for a programming-languages journal with typed-effects / reactive-programming interest."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"Punchline: Willow is a clean, well-worked core calculus that makes render timing and handler lifecycle first-class effects, with a real preservation proof and a working inference prototype. That is new relative to λreact, React-tRace, and the temporal/FRP line, and it targets a pain people actually hit (useEffect loops, races, stale listeners).\n\nWhat they did well: the two-phase semantics is readable; the effect grammar (○ with mixed units, 2/3/⊘/7, ∗/+) is a genuine design contribution, not a thin rebrand of next-modality FRP; subeffecting and the causes judgement are spelled out; Appendix F is a serious configuration/declaration/expression preservation development against an instrumented trace semantics. The signup-form case study is the right kind of example—stuck loading, race, intentional retry loop—and the prototype actually infers the paper’s examples. Citation pattern is normal and engaged.\n\nSoft spots, in proportion. Preservation (Thm 6.1) only guarantees that a changed variable’s Δ cascade shows up as a justified next-housekeeping queue under their simplified model. The multi-render “full effect” expansion and the cascade/loop/stale-listener graph walks in §5.4 are not stated as a corollary tying operational multi-render traces to paths/cycles in that graph (mixed units and + branches included). That is a real gap between the theorem and the abstract’s strongest sentence, not a hole in the one-step math. Second, they deliberately drop mount/unmount, concurrent lanes, and dynamic event ids; they say so, and transfer to production React is therefore aspirational until vertex-style naming lands. Evaluation is illustrative micro-patterns, not a corpus study—fine for a calculus paper, weak if sold as “practical foundation” without sharper bounds.\n\nWho it’s for: PL people in effects, FRP, and GUI semantics; also tool builders thinking about React linters. Worth a serious referee. I would bring it to reading group, engage the formal core, and push them to either prove the graph expansion or fence the claims to “analyses on sound one-step effects.” Not a desk reject.","headline":"Solid PL core calculus with a real effect algebra for React-style timing; the multi-render graph story is useful but less formally pinned than the one-step preservation.","tokens_in":58610,"tokens_out":551,"would_cite":true,"duration_ms":21398,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"Willow turns React-style render timing into checkable effects so cascades, loops, and stale handlers show up before runtime.","keywords":["reactive programming","type-and-effect systems","React","temporal dependency graphs","render semantics","event handler lifecycle","graded modalities","static analysis"],"falsifier":"Port the checker to a non-toy React hooks codebase that uses dynamic component mount/unmount and concurrent features; if the inferred graphs miss known render loops or stale-listener bugs that appear in the real runtime, or flood false positives on correct code, the transfer claim fails.","tokens_in":58455,"feed_emoji":"⏱️","tokens_out":887,"duration_ms":20691,"temperature":0.7,"pith_summary":"Interactive UI frameworks let you declare how the screen depends on state, but they hide when updates fire, when handlers bind or unbind, and how one change can cascade into many renders. Willow is a small React-inspired calculus that makes that timing first-class: a two-phase semantics (render, then housekeeping) paired with a type-and-effect system. Effects record delayed state changes with a graded “next” modality counted in renders, milliseconds, or network trips, and a family of modalities for registering, firing, canceling, and removing event handlers. Those effects form a temporal dependency graph, so ordinary graph walks can flag long render cascades, inter-render loops, expensive high-frequency handlers, missing cleanups, and first-paint cost. The authors prove that well-typed programs preserve their effect annotations under an instrumented semantics, ship a prototype with automatic inference, and show it surfacing stuck loading states, request races, and update loops in realistic patterns like debounce and signup forms.","feed_headline":"Type effects that catch React render loops before runtime","feed_subtitle":"Willow turns update timing into a graph so cascades, races, and stale handlers show up at compile time","key_machinery":"The temporal dependency graph built from Willow effects—especially the graded next modality ○ᴺᵘ and the handler lifecycle modalities 2/3/⊘/7—carries the argument: effects over-approximate when state may change and when listeners are bound or torn down, and graph expansion recovers full multi-render consequences including loops.","core_discovery":"Time-aware typing of render-based reactive programs is practical: if you treat renders as the unit of time and track state updates plus the full event-handler lifecycle as graded effects, the resulting temporal dependency graph lets standard graph algorithms statically catch the timing bugs that framework runtimes usually bury, and those effects are preserved by a time-aware operational semantics.","pith_inferences":["Extending the system with dependent vertex structures for dynamic mount/unmount, as the paper itself flags, is the main bridge from the core calculus to production React tooling.","The same graded-next and handler-lifecycle effects could likely annotate other virtual-DOM or signal-based UI runtimes, not only React-shaped ones.","Once effects are in the type, CI could gate merges on “no new inter-render loops” or “no unbound high-frequency handlers” the way linters gate complexity today."],"forward_implications":["Debounce, form validation, and API-check patterns can carry types that visibly place network work behind timers and show race or stuck-status bugs at compile time.","Inter-render feedback loops and missing handler cleanups become graph properties rather than runtime surprises.","First-render cost and high-frequency expensive handlers can be warned about from the same effect graph without running the app.","Library authors can expose temporal contracts (e.g. “this fetch is debounced”) that compose through parent components via effect polymorphism."],"fun_headline_variants":["Willow types React timing so render loops show up before runtime","Temporal effects turn React updates into a graph compilers can check","Catch render cascades and stale handlers with graded time effects","Type-and-effect system flags React races via temporal dependency graphs","Renders as time units: static graphs expose reactive non-termination"],"cache_read_input_tokens":128,"weakest_assumption_plain":"The simplified two-phase model (no mount/unmount, no concurrent scheduler lanes, only static event labels) is close enough to real React that the static warnings still mean something in production apps.","fun_headline_variants_meta":{"raw":{"variants":["Willow types React timing so render loops show up before runtime","Temporal effects turn React updates into a graph compilers can check","Catch render cascades and stale handlers with graded time effects","Type-and-effect system flags React races via temporal dependency graphs","Renders as time units: static graphs expose reactive non-termination"]},"model":"grok-4.5","effort":"low","cost_usd":0.001986,"raw_usage":{"total_tokens":928,"prompt_tokens":841,"num_sources_used":0,"completion_tokens":67,"cost_in_usd_ticks":19864000,"prompt_tokens_details":{"text_tokens":841,"audio_tokens":0,"image_tokens":0,"cached_tokens":128},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":20,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":841,"tokens_out":67,"duration_ms":2665,"temperature":1.0,"reasoning_tokens":20,"cache_read_input_tokens":128,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-30T11:56:00.655640+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Port the checker to a non-toy React hooks codebase that uses dynamic component mount/unmount and concurrent features; if the inferred graphs miss known render loops or stale-listener bugs that appear in the real runtime, or flood false positives on correct code, the transfer claim fails.","supporting_citations":[],"review_version":1}