Native OpenQASM 2.0/3.0 Translation and Expanded Qiskit Support in contrib

Background & Context

I recently submitted PR #4613 which expanded the interoperability features within the cudaq.contrib module. The PR was labeled with a wontfix without additional feedback.

Since the PR was an iteration over my previously merged work in the same module, I am opening this issue to shift the conversation from a code review to a high-level architectural discussion. I would love to understand the core team's roadmap regarding OpenQASM parsing and framework interoperability, and see if the concepts proposed hold value for the project's future.

Motivation & The Gap

Currently, translating OpenQASM into CUDA-Q relies heavily on external dependencies. The proposal aims to solve two main pain points for users:

1. Dependency Overhead: Relying on Qiskit just to parse OpenQASM introduces unnecessary overhead. A native, zero-dependency translator simplifies the pipeline.
2. OpenQASM 3.0 Support: As the ecosystem moves towards OpenQASM 3.0, having first-class support (declarations, built-in gates, assignments) is becoming critical.
3. Qiskit Round-tripping: The existing from_qiskit coverage is somewhat limited. Expanding the dispatch table ensures users can round-trip circuits built with the full Qiskit standard library (qelib1.inc / stdgates.inc) without silent failures.

Proposed Solution (Proof of Concept)

The closed PR serves as a fully tested Proof of Concept for this architecture. The key features implemented were:

• Native OpenQASM Translator (from_qasm_str, from_qasm): A pure-Python parser dispatching on the OPENQASM <version>; header.
  • _QASM2Translator: Covers the full qelib1.inc gate set, user-defined gates with recursive expansion, and register broadcasting.
  • _QASM3Translator: Adds the 3.0 surface (qubit[N], c = measure q;, etc.).
  • Includes a safe expression evaluator built on ast.parse for parameter expressions.
• Expanded from_qiskit: Replaced ad-hoc if/elif with a comprehensive _GATE_HANDLERS dictionary covering parametric families and multi-qubit gates, staying in lockstep with the QASM semantics.

Discussion Questions for Maintainers

I understand that a wontfix usually means the approach conflicts with internal plans. To help align community contributions with the CUDA-Q vision:

1. Is the translation of OpenQASM 2.0/3.0 currently being developed at the C++ compiler/core level, making a Python contrib approach redundant?
2. If a native Python parser is not desired, would the team be open to merging only the expanded Qiskit gate coverage (from_qiskit improvements) in a separate PR?
3. What is the current policy/roadmap for the cudaq.contrib module moving forward?

Thanks for your time and for maintaining this great framework!

Start by reviewing PR #4613 and the cudaq.contrib entry points named in the proposal: from_qasm_str, from_qasm, and from_qiskit. The issue is ready when maintainers clarify whether native OpenQASM support, expanded Qiskit coverage, or neither fits the project's roadmap and contribution scope.