REVIEW 4 major objections 6 minor 5 references
Compiling a Q# Subset to QASM 3.0 in TypeScript via a JSON Based IR
T0 review · 4 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash
Pith's one-line read A TypeScript-based compile toolchain lowers a practical subset of Q# to QASM 3.0, with runtime close to the official Rust-based toolchain.
desk verdict An honest engineering report on a TypeScript Q#→QASM 3.0 compiler; the artifact is real, but the evidence is demo-level, not validation-grade. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing mechanism is a JSON-serializable abstract syntax tree built by recursive descent. Each AST node carries a `.repr` string that records the node's source-level expression; nested expressions are flattened into these strings, so the compiler can translate Q# to QASM by string substitution rather than by walking deep expression trees. The compiler then pattern-matches on node types (for example `Rxx`, `Measure`, `for` loops) and emits QASM 3.0 templates, inserting the stored `.repr` values. Type information is inferred only when a literal is present, which lets the compiler choose QASM integer widths (`int[8]` through `int[64]`) for loop bounds.
What would settle it
Compile a Q# program that stays inside the claimed supported subset but uses a `repeat` loop, a `borrow` statement, or an expression with a function call whose argument is a variable rather than a literal, then run the emitted QASM 3.0 on a simulator and compare measurement statistics with the official Q# toolchain; any divergence in behavior or a compile-time crash would falsify the claim that the toolchain compiles the supported subset correctly.
Extended reading notes
Core claim
The central claim is that a Q# to QASM 3.0 compiler does not require the native-code toolchain; a TypeScript implementation with a full-featured lexer and parser, plus a JSON-based intermediate representation, can compile a practical subset of Q# into valid QASM 3.0. The paper demonstrates this with the Grover.qs example, showing the AST for operations and functions, and with concrete gate decompositions such as Rxx, Ryy, and Rzz. It further claims that the TypeScript toolchain's total compile time for Grover.qs is 7.60 ms, only 0.31 ms slower than the official Rust-based toolchain, with parsing accounting for 4.76 ms of that total. The conclusion is that the implementation 'manages to port functionality to one of the most portable and interoperable environments available' at little efficiency cost.
Load-bearing premise
The toolchain's correctness rests on the assumption that the few example programs used for demonstration, such as Grover.qs, exercise the supported feature set well enough to reveal any compiler bugs; the paper admits it 'has not been thoroughly tested' and 'only been run against a few input Q# programs.'
Editorial extensions
If this is right
- Q# programs within the supported subset can be compiled and run in web browsers or JavaScript-based quantum simulators, since the whole toolchain is TypeScript.
- The JSON AST makes the pipeline inspectable and reusable: each stage (lexer, parser, compiler) can be invoked independently, and an alternative backend could consume the AST to generate other formats.
- Intrinsic Q# operations that are absent from QASM 3.0's standard gate set, such as Rxx, Ryy, Rzz, and basis-aware Measure, can be lowered to equivalent QASM instruction sequences.
- The timing breakdown (1.12 ms compilation, 4.76 ms parsing, 1.72 ms lexing) indicates parsing, not code generation, is the bottleneck, pointing future optimization effort at the parser.
Reading between the lines
- If the approach scales to the full Q# language, the JSON AST could serve as a neutral interchange format between Q# front ends and multiple quantum back ends, not just QASM 3.0.
- The same string-based `.repr` trick that simplifies the compiler could also make the toolchain easier to formally verify, since the translation from AST to QASM becomes a set of local string templates.
- A natural stress test would be to compile Q#'s standard library samples beyond Grover.qs; the paper's own warning that only 'a few input Q# programs' were tested suggests the correctness claim is still provisional.
- Because the compiler only infers types from literals, extending type inference to variables would allow the same integer-width optimization to apply more widely, potentially closing the remaining performance gap.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper describes a TypeScript-based compile toolchain that lexes and parses a subset of Q# into a JSON-like abstract syntax tree (AST) and then emits OpenQASM 3.0 code. The implementation includes a recursive-descent parser, an AST with expression and control-flow nodes, and a compiler pass that lowers Q# intrinsic gates and language constructs to QASM 3.0. The authors demonstrate the tool on a portion of Grover's algorithm, show AST dumps and generated QASM snippets for gates such as Rxx, Ryy, Rzz, and Measure, and report that compiling Grover.qs takes 7.60 ms versus 7.29 ms for Microsoft's Rust-based toolchain. The paper claims that this is the first step toward a web-portable Q# compiler with competitive performance.
Significance. If the toolchain is correct and reasonably complete, it would be a useful contribution to web-based quantum programming: it shows that a Q# front end can be implemented in TypeScript, that the resulting parser can handle substantial Q# syntax, and that generated QASM 3.0 code can be produced in time comparable to a native Rust implementation. The paper is transparent about its current limitations, and the included AST dumps and QASM snippets provide concrete evidence that the pipeline runs on the demonstrated examples. However, the manuscript's central claim is currently supported only by a few hand-picked examples and self-reported timing numbers; there is no systematic test suite, no independent semantic validation of the emitted QASM, and no differential comparison with a reference compiler on a range of inputs. These gaps are load-bearing because the paper explicitly concedes that the toolchain has not been thoroughly tested and that bugs are expected.
major comments (4)
- [Section 5, final paragraph] The paper states: "The toolchain also has not been thoroughly tested due to time constraints. Therefore, we expect that there may be bugs... The lexer, parser and compiler have also only been run against a few input Q# programs to verify that they basically work as intended." This is a direct admission that the central claim -- that the compiler supports a subset of Q# features -- is not backed by systematic evidence. I ask the authors to provide a proper test suite that exercises each advertised lexer token, each parser construct listed in Section 3, and each intrinsic gate listed in Section 4, with expected outputs. Differential testing against Microsoft's Q# compiler on the same inputs would be the most convincing form of validation, since it checks semantic equivalence of the generated QASM rather than merely checking that the pipeline terminates.
- [Section 4, Rxx/Ryy/Rzz and Measure examples] The generated QASM for the intrinsic gates is presented without any equivalence argument or external check. For example, the Rxx lowering is an unusual sequence of u3, h, cx, u1, cx, h, u2, and the Measure lowering inserts basis-changing gates before a computational-basis measurement. A reader cannot tell whether these sequences are correct, and a single wrong decomposition would falsify the claim that the compiler correctly supports that intrinsic. I ask the authors to verify each lowering by comparing the unitary implemented by the emitted QASM with the intended Q# operation, or at least by running the generated QASM in an OpenQASM-compatible simulator and comparing measurement statistics with the Q# program.
- [Section 5, timing comparison] The performance claim rests on a single pair of numbers (7.60 ms vs. 7.29 ms) with no methodology: no number of runs, no warm-up, no hardware/software environment, no variance, and no clear statement of what is included in each measurement. The text says Microsoft's toolchain takes time to "compile and execute" while the authors' number is called "compile time," so it is unclear whether the two figures measure the same thing. Please provide a reproducible benchmarking procedure and report median and spread over multiple runs, with a clear description of the exact command executed for each toolchain.
- [Sections 3 and 4] The paper shows excerpts of AST dumps and QASM output but not a complete end-to-end compilation of a full program from source Q# to final QASM 3.0. For instance, the Grover.qs example is presented as separate AST fragments, and the generated QASM for the full Grover program is not shown. Without a complete input/output pair, it is hard to assess whether the compiler correctly composes loops, functions, use statements, and gate applications. Please include at least one full program and its complete generated QASM in an appendix or as supplementary material, and explain how the parts shown in the paper fit into that whole.
minor comments (6)
- [Throughout] The manuscript contains numerous typos and grammatical errors, including "folloring", "segement", "conveniece", "knowns", "demarking", "expresion", "subit", and "sompiled". A careful proofreading pass is needed.
- [Section 3] The notation "inputQubits [...2...]" in the AST dump is unclear to readers unfamiliar with Q# range syntax. Please explain that this represents a range with unspecified lower and upper bounds, or show the actual Q# source construct that produces it.
- [Section 2] The lexer section says the supported tokens are "derived from the syntax of Q#" but gives no version or reference to a formal grammar. Please cite the specific Q# language specification or documentation version used.
- [Section 4] The paper mentions "demo.qs" and "demo.qasm" in the "spec" directory but does not provide a repository URL or artifact DOI. Please make the code and examples publicly available and cite the repository in the paper.
- [Section 4, Ryy example] The Ryy lowering uses a "cy" (controlled-Y) gate, which is not part of the core OpenQASM 3 instruction set and would require a definition or include. The paper should clarify whether "cy" is available in the target QASM 3 environment or must be decomposed further.
- [Section 5, Measure example] The Measure code uses "this.qubits.indexOf(qubit)" to determine the classical bit index. If "qubit" is an element of a register array, this index lookup may not map correctly to the physical qubit index. Please clarify the intended semantics and verify this case.
Circularity Check
No circular reasoning; the toolchain implementation and benchmark are self-contained, with only non-load-bearing self-citations.
full rationale
The paper's central claim is an engineering implementation: a lexer, recursive-descent parser, and compiler from a Q# subset to QASM 3.0. Its evidence consists of printed AST segments, compiler code that rewrites AST nodes into QASM strings, demo inputs/outputs, and a runtime comparison against Microsoft's Rust-based toolchain. No fitted parameter is later renamed as a prediction, and no definition imports the target result. The self-citations, [Edw23] and [KE24], appear only as inspiration for parser structure and as support for the claim that TypeScript is a reasonable middle-ground language; they do not carry the correctness or performance claims. The Section 5 admission that 'the toolchain also has not been thoroughly tested... only been run against a few input Q# programs' is a validation weakness and a correctness risk, but it is not circular reasoning: under-testing does not make the derivation equivalent to its inputs. The benchmark against Microsoft's independent toolchain further grounds the central claim externally. Therefore, there is no significant circularity.
Assumptions & free parameters
assumptions (3)
- domain assumption Q# language syntax and semantics are exactly as documented by Microsoft.
- domain assumption The QASM 3.0 specification, as given by [CJAA+22], is a faithful definition of the target language.
- domain assumption The internal AST representation preserves all information needed for correct compilation.
Cite this review
Pith. "Pith review of Compiling a Q# Subset to QASM 3.0 in TypeScript via a JSON Based IR." pith.science (2026). https://pith.science/paper/DBRA7LVM
@misc{pith2026250623407,
author = {Pith},
title = {Pith review of: Compiling a Q# Subset to QASM 3.0 in TypeScript via a JSON Based IR},
year = {2026},
howpublished = {\url{https://pith.science/paper/DBRA7LVM}},
note = {Machine review of arXiv:2506.23407}
}
read the original abstract
We implement a compile toolchain from Q# to QASM 3.0 including a full-featured lexer and parser implementation, as well as a compiler that supports a subset of Q# features. The lexer, parser and compiler are shown to work with various input Q# programs and the implementation is compared against existing Q# compile tools. Unlike the Microsoft implementation of the official Q# compile toolchain, our implementation is written in TypeScript in order to port functionality to web environments.
Reference graph
Works this paper leans on
-
[1]
Andrew Cross, Ali Javadi-Abhari, Thomas Alexander, Niel De Beaudrap, Lev S. Bishop, Steven Heidel, Colm A. Ryan, Prasahnt Sivarajah, John Smolin, Jay M. Gambetta, and Blake R. Johnson. Openqasm 3: A broader and deeper quantum assembly language. ACM Transactions on Quantum Computing , 3(3):1–50, September 2022
work page 2022
-
[2]
Three quantum programming language parser implementations for the web, 2023
Marcus Edwards. Three quantum programming language parser implementations for the web, 2023
work page 2023
-
[3]
Sean Kim and Marcus Edwards. Enabling the verification and formalization of hybrid quantum-classical computing with openqasm 3.0 compatible qasm-ts 2.0, 2024
work page 2024
- [4]
-
[5]
Q\#: Enabling Scalable Quantum Computing and Development with a High-level DSL
Krysta Svore, Alan Geller, Matthias Troyer, John Azariah, Christopher Granade, Bettina Heim, Vadym Kliuchnikov, Mariia Mykhailova, Andres Paz, and Martin Roetteler. Q\#: Enabling Scalable Quantum Computing and Development with a High-level DSL . In Proceedings of the Real World Domain Specific Languages Workshop 2018 , RWDSL2018. ACM, February 2018
work page 2018
Reviewed August 6, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.