pith. machine review for the scientific record. sign in

arxiv: 2604.26967 · v2 · submitted 2026-04-17 · 💻 cs.PL

Recognition: unknown

Literate Execution

Andrew McNutt, Cristina David, Dominic Orchard, Jacob Pake, Joe Bond, Roly Perera, Trevor Sseguya Muwonge

Pith reviewed 2026-05-10 07:51 UTC · model grok-4.3

classification 💻 cs.PL
keywords literate executionliterate programmingprovenance trackingFluid languagevisualizationexplorationexpositionself-explanatory programs
0
0 comments X

The pith

Literate execution inverts literate programming by treating documentation and visualizations as first-class computed artifacts integrated into a running program's view via provenance tracking.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper proposes literate execution as an inversion of Knuth's literate programming, where instead of embedding code in static prose, documentation and visualizations are treated as dynamic, first-class elements computed alongside the program. This is realized in the Fluid language through a provenance-tracking runtime that records fine-grained dependencies between inputs and outputs, surfacing them for interactive exploration of how values contribute to results. The approach integrates visualization, provenance, and exposition to make programs more self-explanatory and explorable explanations easier to create. A sympathetic reader would care because it promises to close the gap between executing code and understanding its behavior through live, traceable narratives.

Core claim

We propose literate execution, which inverts the literate programming relationship by treating documentation and expository elements such as visualisations as first-class artefacts that can be computed alongside a running program and then integrated into a view of its execution. We explore this idea through Fluid, a programming language with a provenance-tracking runtime that records fine-grained dependencies between inputs and outputs. These provenance relationships can be surfaced as interactions that allow readers to explore how intermediate values contribute to a result.

What carries the argument

The provenance-tracking runtime in Fluid, which records fine-grained dependencies between inputs and outputs to enable interactive exploration of how intermediate values contribute to results.

If this is right

  • Documentation and visualizations become dynamically computed and updated in tandem with program execution.
  • Interactive provenance links allow readers to trace how specific inputs and intermediates affect final outputs.
  • Programs gain self-explanatoriness through direct integration of explanatory elements at runtime.
  • Explorable explanations become programmable using the same mechanisms as the core application logic.
  • The combination of visualization, provenance, and exposition makes both code and its descriptions more explorable.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The technique could extend to live educational environments where learners manipulate explanations that stay synchronized with running examples.
  • It offers a path to improve debugging workflows by letting developers navigate code behavior through narrative and visual provenance views.
  • Adoption might influence notebook-style environments by adding automatic dependency tracking without manual cell management.
  • Domain-specific languages for science or data analysis could incorporate this to make computational narratives more transparent and reproducible.

Load-bearing premise

A provenance-tracking runtime can be implemented to capture fine-grained dependencies in a way that meaningfully supports interactive exploration of documentation and visualizations.

What would settle it

A complete Fluid implementation where users cannot trace meaningful fine-grained dependencies when interacting with integrated documentation or visualizations, either due to missing provenance data or excessive performance cost.

Figures

Figures reproduced from arXiv: 2604.26967 by Andrew McNutt, Cristina David, Dominic Orchard, Jacob Pake, Joe Bond, Roly Perera, Trevor Sseguya Muwonge.

Figure 1
Figure 1. Figure 1: This work extends our prior work [2, 25] on automatic visualisation of dependencies by introducing ‘doc comments’ and intermediate value exploration to facilitate literate execution. Here we show how these new features can be used to explain matrix convolution. away. But alongside this essential difficulty, there is a large component of accidental complexity. Authoring systems such as Idyll [6] and Living … view at source ↗
Figure 2
Figure 2. Figure 2: Transparent climate reporting example work. We now describe the syntax (§ 3.1), semantics (§ 3.2), and UI/interaction implementation (§ 3.3) in more detail. 3.1 Pythonic Syntax The core of the new syntax is given in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Fluid’s new Pythonic surface syntax One of the points in which our syntax diverges somewhat from Python is in paragraph literals f"""𝑤""". These are composed of sequences of paragraph elements 𝑤, and are delimited by f"""...""", similar to Python’s mechanism for a triple quoted string. A paragraph element is either a token 𝑡, which corresponds to a string literal, or an unquoted term {𝑠}, which corresponds… view at source ↗
Figure 4
Figure 4. Figure 4: Relevant rules from the semantics for doc comments, including the auxiliary desugarings. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: DDG slice induced by selecting an output cell in Example 1 (convolution). Pink dependency edges [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Python example of docstrings (left) and a literate-execution style approach via a custom macro (right). [PITH_FULL_IMAGE:figures/full_fig_p011_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Syntax of the core language, including values labeled with addresses [PITH_FULL_IMAGE:figures/full_fig_p016_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Desugaring for terms, environments and closures [PITH_FULL_IMAGE:figures/full_fig_p017_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Desugaring for function definitions comprehension. It starts with just 𝑝 and ends up empty. The second component stores remaining top-level patterns and is empty except for in curried functions. We omit desugaring rules for the terms that are uninteresting or obvious – i.e. the terms which are structurally identical between the surface and core languages. As convenient notation, we define the following, wh… view at source ↗
Figure 10
Figure 10. Figure 10: Completing an (uncurried) clause with a default value of [PITH_FULL_IMAGE:figures/full_fig_p019_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Operational semantics with dependence graph [PITH_FULL_IMAGE:figures/full_fig_p020_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Pattern matching 𝛾,𝑚,𝐺 m⇒ 𝑣,𝐺′ m⇒-module 𝛾𝑖−1 , 𝑑𝑖 d⇒ 𝛾𝑖 ,𝐺𝑖 ∀1 ≤ 𝑖 ≤ 𝑛 𝛾0 , 𝑑,𝐺0 m⇒ 𝛾𝑛 ,𝐺𝑛 𝑛 = |𝑑| m⇒-program 𝛾0 , 𝑑 m⇒ 𝛾𝑛 ,𝐺𝑛 𝑠 ↠ 𝑒 𝛾𝑛 , 𝑒, ∅,𝐺𝑛 ⇒ 𝑣,𝐺 ∀1 ≤ 𝑖 ≤ 𝑛 𝛾0 , 𝑑 𝑠 m⇒ 𝑣,𝐺 𝑛 = |𝑑| 𝛾, 𝑑,𝐺 d⇒ 𝛾_,𝐺_ d⇒-def 𝑝 ↠ 𝑥 𝛾, 𝑒,𝑉 ,𝐺1 ⇒ 𝑣,𝐺2 𝑣 , 𝑥 ⇝ 𝛾_,𝐺3 𝛾, def 𝑝: 𝑒,𝑉 ,𝐺1 d⇒ 𝛾_,𝐺2 ∪ 𝐺3 d⇒-fun-clause 𝛾_((𝑥𝑖 )) = cl(𝛾, 𝜌, 𝜌((𝑥𝑖 )))𝛼𝑖 def 𝑥( #”𝑝 ): 𝑠,𝐺 ↣ 𝜎,𝐺_ 𝛾, def 𝑥( #”𝑝 ): 𝑠 d⇒ 𝛾_,𝐺_ [PITH_FULL_IMAGE:figures/f… view at source ↗
Figure 13
Figure 13. Figure 13: Evaluation of Modules and Programs PLATEAU Workshop on Programming Languages and Human-Computer Interaction. Publication date: May 2026 [PITH_FULL_IMAGE:figures/full_fig_p021_13.png] view at source ↗
read the original abstract

\emph{Literate programming}, introduced by Knurth, interleaves code and prose so that a program can be read as both executable and explanatory text. We propose \emph{literate execution}, which inverts this relationship: rather than embedding code within a static narrative, we treat documentation -- and other expository elements such as visualisations -- as first-class artefacts that can be computed alongside a running program and then integrated into a view of its execution. We explore this idea through Fluid, a programming language with a provenance-tracking runtime that records fine-grained dependencies between inputs and outputs. These provenance relationships can be surfaced as interactions that allow readers to explore how intermediate values contribute to a result. By integrating visualisation, provenance, and exposition, literate execution aims to make programs more explorable and self-explanatory, and explorable explanations easier to program.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The manuscript proposes literate execution as an inversion of Knuth's literate programming: rather than embedding code in static prose, it treats documentation and visualizations as first-class, computable artefacts that are generated alongside program execution. The core vehicle is Fluid, a language whose provenance-tracking runtime records fine-grained input-output dependencies; these relationships are intended to be surfaced through interactive views that let readers explore how intermediate values contribute to results, thereby making programs more explorable and self-explanatory while easing the construction of explorable explanations.

Significance. If the provenance mechanism can be realized with acceptable overhead and usable interaction primitives, the idea could meaningfully advance program comprehension tools and the design of interactive explanatory media. The framing is novel in its explicit integration of provenance, visualization, and exposition as co-equal artefacts, and the absence of free parameters or fitted models in the proposal is a strength. However, the current manuscript supplies no concrete mechanism, data model, or example, so the significance remains prospective rather than demonstrated.

major comments (2)
  1. [Abstract] The central claim that 'provenance relationships can be surfaced as interactions' (abstract) is load-bearing for the entire proposal, yet the manuscript provides neither a data model for the dependency graph, a description of how fine-grained provenance is captured at runtime, nor even a single worked example showing how a reader query would traverse provenance to update a live visualization or explanatory text.
  2. The weakest assumption—that a provenance-tracking runtime can deliver interactive exploration without collapsing under realistic program complexity—is never examined; there is no discussion of granularity choices, storage overhead, or how the runtime would scale beyond trivial examples.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their careful reading and constructive feedback on our manuscript. We value the recognition of the conceptual novelty in framing literate execution as an inversion of traditional literate programming. We address the major comments below and will incorporate revisions to strengthen the presentation of the core ideas.

read point-by-point responses

  1. Referee: [Abstract] The central claim that 'provenance relationships can be surfaced as interactions' (abstract) is load-bearing for the entire proposal, yet the manuscript provides neither a data model for the dependency graph, a description of how fine-grained provenance is captured at runtime, nor even a single worked example showing how a reader query would traverse provenance to update a live visualization or explanatory text.

    Authors: The manuscript presents literate execution primarily as a conceptual proposal rather than a fully engineered system. The abstract summarizes the intended role of provenance, but we agree that the absence of an explicit data model and illustrative example leaves the claim insufficiently grounded. In revision we will add a concise section outlining a high-level provenance data model (based on input-output dependency records maintained by the Fluid runtime) together with a short worked example that demonstrates how a reader interaction could query the provenance graph to update a visualization or explanatory text. revision: yes

  2. Referee: The weakest assumption—that a provenance-tracking runtime can deliver interactive exploration without collapsing under realistic program complexity—is never examined; there is no discussion of granularity choices, storage overhead, or how the runtime would scale beyond trivial examples.

    Authors: We concur that the manuscript does not examine the engineering trade-offs of provenance tracking. Because the paper focuses on the paradigm shift rather than implementation, these practical considerations were omitted. We will add a brief discussion of granularity choices, expected storage costs, and scaling considerations, drawing on existing literature in fine-grained provenance systems to indicate feasible directions without claiming a complete solution. revision: yes

Circularity Check

0 steps flagged

No circularity: conceptual proposal with no derivations or self-referential predictions

full rationale

The paper is a high-level proposal for literate execution via the Fluid language and its provenance-tracking runtime. It contains no mathematical equations, fitted parameters, predictions derived from data, or first-principles derivations that could reduce to their own inputs. The central claims concern the potential integration of visualization, provenance, and exposition; these are framed as a new approach rather than results obtained by construction from prior results or self-citations. No load-bearing self-citations, uniqueness theorems, or ansatzes appear in the provided text. The derivation chain is therefore self-contained and non-circular by the criteria.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The proposal rests on the assumption that provenance tracking can be made fine-grained enough to support interactive exploration without specifying how this is achieved or validated.

axioms (1)
  • domain assumption Provenance relationships between inputs and outputs can be recorded at a fine-grained level during execution
    Invoked as the foundation for surfacing interactions in the Fluid runtime.
invented entities (1)
  • Fluid programming language no independent evidence
    purpose: Vehicle for exploring literate execution with provenance tracking
    Introduced as the concrete system in which the idea is demonstrated.

pith-pipeline@v0.9.0 · 5448 in / 1157 out tokens · 51369 ms · 2026-05-10T07:51:38.348277+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

45 extracted references · 30 canonical work pages

  1. [1]

    Thomas Baudel. 2006. From Information Visualization to Direct Manipulation: Extending a Generic Visualization Framework for the Interactive Editing of Large Datasets. InProceedings of the 19th Annual ACM Symposium on User Interface Software and Technology (Uist ’06). Association for Computing Machinery, Montreux, Switzerland, 67–76. doi:10.1145/1166253.1166265

    work page doi:10.1145/1166253.1166265 2006

  2. [2]

    Joe Bond, Cristina David, Minh Nguyen, Dominic Orchard, and Roly Perera. 2025. Cognacy Queries over Dependence Graphs for Transparent Visualisations. InProgramming Languages and Systems, Viktor Vafeiadis (Ed.). Springer Nature Switzerland, Cham, 144–171

    2025

  3. [3]

    Frederick P. Brooks. 1987. No Silver Bullet: Essence and Accidents of Software Engineering.Computer20, 4 (1987), 10–19

    1987

  4. [4]

    Yiru Chen and Eugene Wu. 2022. PI2: End-to-end Interactive Visualization Interface Generation from Queries. In Proceedings of the 2022 International Conference on Management of Data. ACM, Philadelphia PA USA, 1711–1725. doi:10.1145/3514221.3526166

    work page doi:10.1145/3514221.3526166 2022

  5. [5]

    2024.Independent Assessment of the Third National Adaptation Programme (NAP3)

    Climate Change Committee. 2024.Independent Assessment of the Third National Adaptation Programme (NAP3)

    2024

  6. [6]

    Matthew Conlen and Jeffrey Heer. 2018. Idyll: A Markup Language for Authoring and Publishing Interactive Articles on the Web. InProceedings of the 31st Annual ACM Symposium on User Interface Software and Technology (Uist ’18). Association for Computing Machinery, Berlin, Germany, 977–989. doi:10.1145/3242587.3242600

    work page doi:10.1145/3242587.3242600 2018

  7. [7]

    Will Crichton and Shriram Krishnamurthi. 2024. A Core Calculus for Documents: Or, Lambda: The Ultimate Document. Proc. ACM Program. Lang.8, POPL (Jan. 2024). doi:10.1145/3632865

    work page doi:10.1145/3632865 2024

  8. [8]

    Pierre Dragicevic, Yvonne Jansen, Abhraneel Sarma, Matthew Kay, and Fanny Chevalier. 2019. Increasing the Transparency of Research Papers with Explorable Multiverse Analyses. InCHI 2019 - the ACM CHI Conference on Human Factors in Computing Systems. Glasgow, United Kingdom. doi:10.1145/3290605.3300295

    work page doi:10.1145/3290605.3300295 2019

  9. [9]

    Stefan Fehrenbach and James Cheney. 2016. Language-Integrated Provenance. InProceedings of the 18th International Symposium on Principles and Practice of Declarative Programming (Ppdp ’16). Association for Computing Machinery, Edinburgh, United Kingdom, 214–227. doi:10.1145/2967973.2968604

    work page doi:10.1145/2967973.2968604 2016

  10. [10]

    Philip J. Guo. 2013. Online Python Tutor: Embeddable Web-Based Program Visualization for CS Education(Sigcse ’13). Association for Computing Machinery, Denver, Colorado, USA, 579–584. doi:10.1145/2445196.2445368

    work page doi:10.1145/2445196.2445368 2013

  11. [11]

    Devamardeep Hayatpur, Brian Hempel, Richard Lin, and Haijun Xia. 2025. The Shapes of Abstraction in Data Structure Diagrams. InProceedings of the 2025 CHI Conference on Human Factors in Computing Systems. ACM, Yokohama Japan, 1–12. doi:10.1145/3706598.3713723

    work page doi:10.1145/3706598.3713723 2025

  12. [12]

    Jeffrey Heer, Matthew Conlen, Vishal Devireddy, Tu Nguyen, and Joshua Horowitz. 2023. Living Papers: A Language Toolkit for Augmented Scholarly Communication. InProceedings of the 36th Annual ACM Symposium on User Interface Software and Technology (Uist ’23). Association for Computing Machinery, San Francisco, CA, USA. doi:10.1145/ 3586183.3606791

    work page arXiv 2023

  13. [13]

    Fred Hohman, Matthew Conlen, Jeffrey Heer, and Duen Chau. 2020. Communicating with Interactive Articles.Distill 5, 9 (Sept. 2020), 10.23915/distill.00028. doi:10.23915/distill.00028

    work page doi:10.23915/distill.00028 2020

  14. [14]

    IPCC. 2021. Summary for Policymakers. InClimate Change 2021: The Physical Science Basis. Contribution of Working Group I to the Sixth Assessment Report of the Intergovernmental Panel on Climate Change, V. Masson-Delmotte, P. Zhai, A. Pirani, S.L. Connors, C. Péan, S. Berger, N. Caud, Y. Chen, L. Goldfarb, M.I. Gomis, M. Huang, K. Leitzell, E. Lonnoy, J.B....

    2021

  15. [15]

    Hyeonsu Kang and Philip J. Guo. 2017. Omnicode: A Novice-Oriented Live Programming Environment with Always-On Run-Time Value Visualizations. InProceedings of the 30th Annual ACM Symposium on User Interface Software and Technology. ACM, Québec City QC Canada, 737–745. doi:10.1145/3126594.3126632

    work page doi:10.1145/3126594.3126632 2017

  16. [16]

    Thomas Kluyver, Benjamin Ragan-Kelley, Fernando Pérez, Brian Granger, Matthias Bussonnier, Jonathan Frederic, Kyle Kelley, Jessica Hamrick, Jason Grout, Sylvain Corlay, Paul Ivanov, Damián Avila, Safia Abdalla, Carol Willing, and Jupyter development team. 2016. Jupyter Notebooks — a Publishing Format for Reproducible Computational Workflows. InPositioning...

    2016

  17. [17]

    Donald E. Knuth. 1984. Literate Programming.Comput. J.27, 2 (May 1984), 97–111. doi:10.1093/comjnl/27.2.97

    work page doi:10.1093/comjnl/27.2.97 1984

  18. [18]

    Brittany Kondo and Christopher Collins. 2014. DimpVis: Exploring Time-Varying Information Visualizations by Direct Manipulation.IEEE Transactions on Visualization and Computer Graphics20, 12 (2014), 2003–2012. doi:10.1109/TVCG. 2014.2346250

    work page doi:10.1109/tvcg 2014

  19. [19]

    Sorin Lerner. 2020. Projection Boxes: On-the-fly Reconfigurable Visualization for Live Programming. InProceedings of the 2020 CHI Conference on Human Factors in Computing Systems (Chi ’20). Association for Computing Machinery, Honolulu, HI, USA, 1–7. doi:10.1145/3313831.3376494 PLATEAU Workshop on Programming Languages and Human-Computer Interaction. Publ...

    work page doi:10.1145/3313831.3376494 2020

  20. [20]

    Damien Masson, Sylvain Malacria, Géry Casiez, and Daniel Vogel. 2023. Charagraph: Interactive Generation of Charts for Realtime Annotation of Data-Rich Paragraphs. InProceedings of the 2023 CHI Conference on Human Factors in Computing Systems. ACM, Hamburg Germany, 1–18. doi:10.1145/3544548.3581091

    work page doi:10.1145/3544548.3581091 2023

  21. [21]

    Milner (Ed.)

    R. Milner (Ed.). 1997.The Definition of Standard ML. MIT Press, Cambridge, Massachusetts

    1997

  22. [22]

    Tanimoto

    Edward Misback, Erik Vank, Zachary Tatlock, and Steven L. Tanimoto. 2025. Codetations: Intelligent, Persistent Notes and UIs for Programs and Other Documents.CoRRabs/2504.18702 (2025). doi:10.48550/ARXIV.2504.18702

    work page doi:10.48550/arxiv.2504.18702 2025

  23. [23]

    2025.Javadoc Tool: Documentation for Java Platform, Standard Edition

    Oracle Corporation. 2025.Javadoc Tool: Documentation for Java Platform, Standard Edition. https://www.oracle.com/ java/technologies/javase/javadoc-tool.html

    2025

  24. [24]

    Proceedings of the 17th ACM SIGPLAN international conference on Functional programming , pages =

    Roly Perera, Umut A. Acar, James Cheney, and Paul Blain Levy. 2012. Functional Programs That Explain Their Work. InProceedings of the 17th ACM SIGPLAN International Conference on Functional Programming (ICFP ’12). ACM, Copenhagen, Denmark, 365–376. doi:10.1145/2364527.2364579

    work page doi:10.1145/2364527.2364579 2012

  25. [25]

    Roly Perera, Minh Nguyen, Tomas Petricek, and Meng Wang. 2022. Linked Visualisations via Galois Dependencies. Proc. ACM Program. Lang.6, POPL (2022). doi:10.1145/3498668

    work page doi:10.1145/3498668 2022

  26. [26]

    Fernando Perez and Brian E. Granger. 2007. IPython: A System for Interactive Scientific Computing.Computing in Science & Engineering9, 3 (2007), 21–29. doi:10.1109/MCSE.2007.53

    work page doi:10.1109/mcse.2007.53 2007

  27. [27]

    2022.Triemaps That Match

    Simon Peyton Jones, Richard Eisenberg, and Sebastian Graf. 2022.Triemaps That Match. Technical Report. https: //simon.peytonjones.org/triemaps-that-match/

    2022

  28. [28]

    Joao Felipe Pimentel, Leonardo Murta, Vanessa Braganholo, and Juliana Freire. 2019. A Large-Scale Study About Quality and Reproducibility of Jupyter Notebooks. In2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR). IEEE, Montreal, QC, Canada, 507–517. doi:10.1109/MSR.2019.00077

    work page doi:10.1109/msr.2019.00077 2019

  29. [29]

    Alfonso Piscitelli, Cristina David, Mattia De Rosa, Ali Muhammad, Federico Nanni, Jacob Pake, Roly Perera, Jessy Sodimu, and Chenyiqiu Zheng. 2025. AI-assisted Authoring for Transparent, Data-Driven Documents. https: //openreview.net/forum?id=pRwc6v6bP1

    2025

  30. [30]

    Fotis Psallidas and Eugene Wu. 2018. Smoke: Fine-Grained Lineage at Interactive Speed.Proc. VLDB Endow.11, 6 (Feb. 2018), 719–732. doi:10.14778/3199517.3199522

    work page doi:10.14778/3199517.3199522 2018

  31. [31]

    pytest-dev Team. 2025. How to Run Doctests - Pytest Documentation. https://docs.pytest.org/en/stable/how- to/doctest.html

    2025

  32. [32]

    Wilmer Ricciotti, Jan Stolarek, Roly Perera, and James Cheney. 2017. Imperative Functional Programs That Explain Their Work.Proceedings of the ACM on Programming Languages1, ICFP (2017), 14:1–14:28. doi:10.1145/3110258

    work page doi:10.1145/3110258 2017

  33. [33]

    Adam Rule, Aurélien Tabard, and James D. Hollan. 2018. Exploration and Explanation in Computational Notebooks. In Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems (CHI ’18). Association for Computing Machinery, Montreal QC, Canada, 1–12. doi:10.1145/3173574.3173606

    work page doi:10.1145/3173574.3173606 2018

  34. [34]

    2025.The Rustdoc Book

    Rust Project Developers. 2025.The Rustdoc Book. https://doc.rust-lang.org/rustdoc/

    2025

  35. [35]

    Matthew Sotoudeh. 2025. Literate Tracing. InProceedings of the 2025 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward! ’25). Association for Computing Machinery, Singapore, Singapore, 143–160. doi:10.1145/3759429.3762626

    work page doi:10.1145/3759429.3762626 2025

  36. [36]

    Sara Steegen, Francis Tuerlinckx, Andrew Gelman, and Wolf Vanpaemel. 2016. Increasing Transparency through a Multiverse Analysis.Perspectives on Psychological Science11, 5 (2016), 702–712. doi:10.1177/1745691616658637

    work page doi:10.1177/1745691616658637 2016

  37. [37]

    Sakutaro Sugiyama, Takashi Kobayashi, Kazumasa Shimari, and Takashi Ishio. 2022. JISDLab: A Web-Based Interactive Literate Debugging Environment. In2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). 497–501. doi:10.1109/SANER53432.2022.00067

    work page doi:10.1109/saner53432.2022.00067 2022

  38. [38]

    Dimitri van Heesch. 2008. Doxygen. https://www.doxygen.nl/

    2008

  39. [39]

    2001.PEP 257: Docstring Conventions

    Guido van Rossum. 2001.PEP 257: Docstring Conventions. Technical Report. Python Software Foundation. https: //peps.python.org/pep-0257/

    2001

  40. [40]

    Bret Victor. 2011. Explorable Explanations. http://worrydream.com/ExplorableExplanations

    2011

  41. [41]

    Bret Victor. 2012. Inventing on Principle. http://worrydream.com/#!/InventingOnPrinciple

    2012

  42. [42]

    Chenglong Wang, Yu Feng, Rastislav Bodik, Alvin Cheung, and Isil Dillig. 2019. Visualization by Example.Proc. ACM Program. Lang.4, POPL (Dec. 2019). doi:10.1145/3371117

    work page doi:10.1145/3371117 2019

  43. [43]

    Chenglong Wang, Yu Feng, Rastislav Bodik, Isil Dillig, Alvin Cheung, and Amy J Ko. 2021. Falx: Synthesis-Powered Visualization Authoring. InProceedings of the 2021 CHI Conference on Human Factors in Computing Systems. ACM, Yokohama Japan, 1–15. doi:10.1145/3411764.3445249

    work page doi:10.1145/3411764.3445249 2021

  44. [44]

    J. Wood, A. Kachkaev, and J. Dykes. 2019. Design Exposition with Literate Visualization.IEEE Transactions on Visualization and Computer Graphics25, 1 (Jan. 2019), 759–768. doi:10.1109/TVCG.2018.2864836

    work page doi:10.1109/tvcg.2018.2864836 2019

  45. [45]

    concrete surface syntax

    Ruishi Zou, Yinqi Tang, Jingzhu Chen, Siyu Lu, Yan Lu, Yingfan Yang, and Chen Ye. 2025. GistVis: Automatic Generation of Word-Scale Visualizations from Data-Rich Documents. InProceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI ’25). Association for Computing Machinery, New York, NY, USA. doi:10.1145/3706598.3713881 PLATEAU Wo...

    work page doi:10.1145/3706598.3713881 2025