Wolfram Language Paclet Repository
Community-contributed installable additions to the Wolfram Language
ParsingOpenQASM
ParsingOpenQASM
OpenQASM is the assembly language quantum hardware speaks - the format qiskit emits and QuantumFramework imports. It is the parser zoo's full-fledged tier: a real DSL with two dialects, a statement grammar, parametrized and modified gates, custom gate definitions, and angle expressions. This note builds up the language a construct at a time, parsing it with combinators into a neutral circuit IR - plain Wolfram data, no QuantumFramework dependency - that an adapter can turn into a QuantumCircuitOperator.
The two entry points are (source to the IR) and (source to the standard syntax tree). Everything below threads one growing example: a Bell circuit, then its variations.
OpenQASMRead
OpenQASMAST
The neutral IR
The neutral IR
A whole program reads to a single with five keys - the version, the includes, the register declarations, any gate definitions, and an ordered list of statements:
In[1]:=
OpenQASMRead["OPENQASM 3.0;\nqubit[2] q;\nh q[0];\ncx q[0], q[1];"]
Out[1]=
Version3,Includes{},Registers{Kindqubit,Nameq,Size2},GateDefs{},Statements{TypeGate,Modifiers{},Nameh,Params{},Qubits{Registerq,Index0},TypeGate,Modifiers{},Namecx,Params{},Qubits{Registerq,Index0,Registerq,Index1}}
Each gate is a record carrying its name, evaluated parameters, modifiers, and a list of qubit references. A qubit reference is itself a small Association: for , for a bare register, for the hardware qubit .
<|"Register"->"q","Index"->0|>
q[0]
<|"Register"->"q"|>
<|"Physical"->0|>
$0
One grammar, two dialects
One grammar, two dialects
OpenQASM 2.0 and 3.0 differ mostly in how they spell register declarations and measurement, so a single grammar handles both and lowers them to the same IR. A declaration production is just an ordered choice over the four spellings:
In[2]:=
regDecl=
[kw["qreg"]~~identTok~~lit["["]~~intTok~~lit["]"]~~lit[";"],(alg["Reg"]["qubit",#2,#4])&],(*v2:qregq[2];*)
kw["qubit"]~~
[lit["["],intTok,lit["]"]]~~identTok~~lit[";"],(alg["Reg"]["qubit",#3,#2])&,(*v3:qubit[2]q;*)...;
 | ParseChoice |
 | ParseAction |
| ParseAction |
 | ParseOptional |
| ParseBetween |
Because both branches call the same builder, the dialects are indistinguishable downstream. The same Bell circuit in v2 and v3 produces identical gate statements:
alg["Reg"]["qubit",name,size]
In[3]:=
OpenQASMRead["OPENQASM 2.0;\nqreg q[2];\nh q[0];"]["Statements"]===OpenQASMRead["OPENQASM 3.0;\nqubit[2] q;\nh q[0];"]["Statements"]
Out[3]=
True
Gate modifiers and angle expressions
Gate modifiers and angle expressions
A gate application carries an optional chain of modifiers (, , , ), an optional parenthesized parameter list, and its qubit arguments. The modifiers parse with a of a small choice, and the parameters run through a precedence grammar over / / built with - so evaluates its angle to a real Wolfram value, while accumulates into the list:
inv@
pow(k)@
ctrl@
negctrl@
pi
tau
euler
rx(pi/2)
inv@pow(2)@
"Modifiers"
In[4]:=
OpenQASMRead["OPENQASM 3.0;\nqubit[1] q;\ninv @ pow(2) @ rx(pi/2) q[0];"]["Statements"]
Out[4]=
TypeGate,Modifiers{Kindinv,ArgMissing[],Kindpow,Arg2},Namerx,Params,Qubits{Registerq,Index0}
π
2
The angle grammar is deliberately closed: its only identifiers are , , and , so an injected Wolfram expression simply has no parse and is refused at the grammar level rather than evaluated.
pi
tau
euler
Custom gate definitions
Custom gate definitions
A block names a sub-circuit. Its body is parsed by the very same statement parser via (the recursion cell ), so a definition's body is a list of ordinary gate records, ready to inline:
gate
stmtRef
In[5]:=
OpenQASMRead["OPENQASM 3.0;\ngate bell a, b { h a; cx a, b; }\nqubit[2] q;\nbell q[0], q[1];"]["GateDefs"]
Out[5]=
{Namebell,Params{},Qubits{a,b},Body{TypeGate,Modifiers{},Nameh,Params{},Qubits{Registera},TypeGate,Modifiers{},Namecx,Params{},Qubits{Registera,Registerb}}}
Measurement and unsupported constructs
Measurement and unsupported constructs
The two measurement spellings - v2's and v3's - both normalize to one record naming the measured qubit and the classical target. And a construct outside the circuit-level subset (classical control flow, timing, ) is recognized by its leading keyword and captured as an record instead of failing the whole read, so a mostly-importable file still yields its importable part:
measureq->c
c=measureq
def
"Unsupported"
In[6]:=
OpenQASMRead["OPENQASM 3.0;\nqubit[1] q;\nwhile (true) { x q[0]; }"]["Statements"]
Out[6]=
{TypeUnsupported,Keywordwhile}
The standard AST
The standard AST
The same grammar, run over the standard-AST algebra instead, gives the syntax tree - each statement a , each qubit reference and keyword a - the algebra-free view shared with every other zoo language:
In[7]:=
Head@OpenQASMAST["OPENQASM 3.0;\nqubit[2] q;\nh q[0];\ncx q[0], q[1];"]
Out[7]=
ContainerNode
From IR to circuit
From IR to circuit
The IR is intentionally neutral: it validates syntax, not semantics. It does not check gate arities, resolve register offsets to absolute wires, or know that is a controlled - those are an importer's job. That separation is the point: QuantumFramework's importer can map this IR's to QuantumOperator elements and assemble a QuantumCircuitOperator, replacing the hand-rolled regex scanner it used before with a real grammar - while the parser itself stays a dependency-free part of the zoo. See the parser zoo guide for the other languages and the shared design.
cx
X
"Statements"
 |
|
""