A Domain-Specific Language for Formulating Hybrid Quantum-Classical Meta-Solver Strategies

AI summary

Overview

Research area: Quantum software engineering, specifically hybrid quantum–classical workflow modeling and domain-specific languages (DSLs) for quantum computing.

Technical level: Intermediate. Readers should be comfortable with basic programming concepts (types, instances, method calls, conditionals, loops) and have a general idea of what hybrid quantum–classical algorithms are; no deep quantum algorithm theory is required.

Scope: The paper proposes and demonstrates a DSL, plus an editor and execution framework built on the ProvideQ toolbox, for writing, sharing, and automatically executing hybrid quantum–classical "Meta-Solver Strategies" that choose between quantum and classical solvers based on problem-specific characteristics.

What This Paper Is About

Designing hybrid quantum–classical workflows requires deciding which parts of a problem are realistic "quantum candidates," and that decision depends heavily on the specific characteristics of the problem, the application, and the available quantum and classical hardware. Because this selection is highly context-dependent, it typically demands scarce expert knowledge, and best practices are not yet well established. The authors introduce a DSL that captures such expert best practices in an easy-to-read, easy-to-share, technology-independent format, along with an editor and an execution framework that runs the resulting strategies through the ProvideQ toolbox.

Key Contributions

1. A DSL for Meta-Solver Strategies. The language models problem types, problem instances, solvers, problem solutions, decisions, and Meta-Solver Strategies, using familiar constructs such as solve blocks, method-call-style solver invocations, mandatory else branches, nested solve statements, foreach loops, and collection types like TSP[].

2. Composable, reusable strategies. Every Meta-Solver Strategy also acts as a solver for its target problem type, so strategies can be called as subroutines inside other strategies, enabling hierarchical composition, reuse, and sharing.

3. A complete toolchain. A web-based editor implemented in TypeScript with the Langium framework (providing syntax highlighting, error checking, and auto-completion informed by ProvideQ problem type and solver definitions), plus a TypeScript execution framework that interprets the Langium-generated abstract syntax tree and calls ProvideQ services via a REST API.

4. An open-source, executed case study. All contributions are released open source on GitHub, and the authors demonstrate end-to-end execution of a composed strategy on two vehicle routing problem (VRP) instances through the ProvideQ toolbox.

Main Findings

• The DSL executes as intended. The same Meta-Solver Strategy, applied to two VRP instances with different characteristics, produced different solution paths, confirming that problem-characteristic-driven branching works at runtime.

• Small instance path. The constructed instance P-n3-k1 was routed directly to the Qrisp quantum solver, which the paper describes as using Grover's algorithm; this is the path shown in purple in the paper's Figure 4.

• Large instance path. P-n19-k2 by Augerat et al., with dimension 19, exceeded the dimension threshold of 4 and was clustered by the 2-Phase clustering approach into 3 TSP clusters with dimensions 11, 8, and 2.

• Per-cluster solver selection. Within that clustering path, the TSP clusters of dimensions 11 and 8 exceeded the per-cluster threshold of 5 and were solved with the classical LKH-3 solver, while the TSP of dimension 2 was transformed into a QUBO problem and solved with a Qrisp quantum solver using QAOA.

• Reported dimension discrepancy. The paper states the constructed instance P-n3-k1 has dimension 3 in one passage and refers to it as "our constructed problem with a dimension of 2" in the results discussion; the two statements are not reconciled in the text.

• No performance evaluation. The authors explicitly state that their focus is practical applicability rather than evaluating the performance of the Meta-Solver Strategies, so no solution quality, runtime, or cost results are reported.

• Positioning against prior work. The authors argue they are the first to pursue a workflow specification and execution mechanism based on a DSL, in contrast to graphical, graph-oriented approaches such as QuantME, Tierkreis, the WMS extension work, GalaxyQ, and the earlier Hybrid Meta-Solving approach; Rigoletto is noted as the one prior non-graphical example, using a JSON format.

Methodology in Plain English

The authors first motivate a DSL over graph-based or low-level API approaches: a DSL hides implementation detail, insulates strategies from unstable quantum APIs and libraries, and produces a single portable artifact that any conforming framework can execute. They then define the language around a small set of concepts — problem type, problem instance, solver, problem solution, decision, and Meta-Solver Strategy — and design the syntax to resemble typed object-oriented programming, with indented blocks after colons, uppercase names for types and lowercase names for instances, and key-value parameters for solver calls. Decisions are written as if/else, but an else branch is mandatory so that a solver always runs and a solution is always produced; return statements are therefore omitted as redundant. Nesting solve blocks expresses decomposition into subproblems, and strategies can call other strategies as solvers.

For implementation, the DSL grammar is written in Langium, which generates a parser, an abstract syntax tree, and a language server backend; the editor adds syntax highlighting, error checking, and auto-completion using problem type and solver information fetched from the ProvideQ toolbox, and stores strategies through a custom backend exposed via a REST API. The execution framework traverses the same AST and issues calls into ProvideQ, which serves as the orchestration layer over backends such as Qiskit, the Kipu Quantum Hub, and GAMS. The case study takes the composed strategy from the paper's Figure 1(b), creates the two VRP instances in ProvideQ, and starts execution through the REST API by passing the stored strategy's identifier and the target problem instance (which must match the strategy's problem type).

Why This Matters

For research, the paper argues that separating solver semantics from concrete backends keeps Meta-Solver Strategies valid as quantum toolchains evolve, and that a single technology-independent artifact simplifies comparison and benchmarking of strategies — a prerequisite the authors identify as missing before systematic evaluation is possible.

Real-world applications implied by the work:

• Logistics and routing. The demonstrated case study is VRP, where large instances are clustered into TSP subproblems and only small subproblems are dispatched to quantum solvers.
• Combinatorial optimization. The paper identifies combinatorial optimization as a principal application area for hybrid quantum–classical workflows.
• Materials simulation. The paper also names material simulation as a typical application domain for such workflows.
• Cross-team sharing of solver expertise. Because strategies are portable text artifacts, an expert's decision logic can be distributed and executed by others without them needing the underlying quantum tooling knowledge.

For industry, the DSL addresses a practical obstacle to adopting quantum computing in production pipelines: unstable APIs, changing libraries, and shifting standards. By fixing the workflow description and letting the framework absorb backend churn, organizations can encode solver-selection policy once and re-execute it against interchangeable quantum simulators, real hardware, and classical solvers as they become available.

Future Directions

• Formalized Meta-Solver Strategies. The authors suggest incorporating formalization ideas from prior work and implementing automated checks in the DSL editor, so users can write validated strategies that are guaranteed to yield correct results.
• Additional execution environments. Implementing backends for the DSL beyond the ProvideQ toolbox, to realize the portability the language is designed for.
• Benchmarking support. Adding tooling to compare different strategies across a range of problem instances and analyze them in terms of solution quality, runtime, and cost — the dimensions the current case study does not measure.
• Broader empirical evaluation. The current demonstration covers two VRP instances only; whether strategies written in the DSL scale to larger and more diverse problem sets remains untested in the paper.

Target Audience

Quantum software engineers and tooling developers; researchers working on hybrid quantum–classical workflow modeling and quantum candidate identification; practitioners in optimization who need to encode expert solver-selection policy in a maintainable, portable form; and readers interested in how DSLs and language-server technology can be applied to quantum computing toolchains.

Authors’ abstract

A key challenge when designing hybrid quantum-classical workflows is the identification of quantum candidates, that is, determining for which specific problems quantum advantages could potentially be achieved. When choosing between several candidates, it is crucial to consider the characteristics specific to the problem, as these can fundamentally determine how successful quantum or classical approaches will be. This implies that specialized expertise is needed to use hybrid quantum-classical workflows successfully. To address this challenge, we propose a domain-specific language (DSL) to express best-practices in solution strategies using a universal representation that is easy to use and share. This DSL provides a flexible approach to design hybrid quantum-classical workflows and to automate decisions for a wide range of problems, supporting decisions down to problem-specific details while remaining technically independent. Furthermore, we propose a framework that is built around our DSL that enables the execution of defined workflows using the ProvideQ toolbox as an orchestration layer. All contributions from this publication are open source.