Eclipse Qrisp Roadmap

[bastibock]

Help us shape the Eclipse Qrisp roadmap

We're building a public roadmap for Eclipse Qrisp and want your input.
This thread collects ideas: features, improvements, pain points, and generally things you think Qrisp should and should not do.

Timeline

• Until October 25th: collect ideas in this thread
• October 29th: in-person discussion at EQCD 2026 in Berlin, where we sort and prioritize and create a timeline
• Afterwards: project leads draft a ROADMAP.md as a pull request, open for comments for ~3 weeks
• Then: regular reviews and updates

How to contribute

Please post one idea per comment so others can reply and 👍 it. A short format helps:

**Idea:** ...
**Topic:** Qrisp core / Backends & interop / Releases / Docs & onboarding / Community / Other
**Horizon:** Now (~4 months) / Next (4–12 months) / Later (12–24 months)
**Why:** one or two sentences
**Can you help with it?** yes / maybe / no

Not sure about topic or horizon? Just leave it out, and we'll sort it.

To get started

A few topics are already on the table. Feel free to comment on these too:

• Quantum Oracle Sketching
• Qudit support
• Static vs Dynamic Mode
• Requirements engineering

👍 reactions help us see interest, but they are a signal, not a vote.

[purva-thakre]

Requirements engineering

Sorry, what does this mean?

[bastibock]

One of Nikos students reverse engineered requirements for the whole Qrisp repository to get in the direction of a requirements analysis.

This might become important if Qrisp is used in critical projects with some security requirements.

But this topic also is only a suggestions for things to discuss.

[rainij]

Idea: Faithful MLIR representation of Qrisp
Topic: Backends & interop
Horizon: Next (4–12 months)
Why: Qrisp expresses high-level semantics which would be valuable for a compiler. The current MLIR interface (jasp) drops this high-level semantics.
Can you help with it? maybe

I and @julfarn could in principle help with dialect design. We likely cannot do it alone. I am also aware that this might be technically challenging. I am not experienced with JAX, somebody mentioned to me that this is not possible with JAX. Would be interesting to know if this is true and what this implies for such a goal.

[purva-thakre]

I am going to add equality saturation to Qrisp's pass manager via tamagoyaki sometime over the next couple of months. I think there is probably some overlap with this idea.

[rainij]

Never heard of e-graphs but sounds interesting in its own. Still missing the connection though: Does it mean that your work would rely on establishing a more expressible (ideally "faithful") MLIR dialect for Qrisp?

[purva-thakre]

Does it mean that your work would rely on establishing a more expressible (ideally "faithful") MLIR dialect for Qrisp?

I think so. Still in the planning stages of understanding what I need to do. My near term goal is to find a way to automate the pass manager pipeline. Right now, the passes have to be applied manually. The advantage of adding tamagoyaki is it allows us to build a multi-level compilation pipeline (end goal). Plus, this tool only consumes an IR. The first step for a while will be to add equality saturation at the circuit level. Then, I want to move to a higher level which will be an overlap with your idea.

[CedricSchacht]

Idea: Software architecture and clean API
Topic: Qrisp core
Horizon: Later (12–24 months)
Why: A solid software architecture reduces the amounts of bugs, and helps developing the framework faster in the long run. Applying design patterns and the guidelines from Clean Code and Clean Architecture, also makes it easier for new people to contribute.
Can you help with it? yes

[CedricSchacht]

This also includes ideas like modularization

[ntchol]

Idea: Requirements Engineering and systematic and transparent development => Tracing of Requirements to Testcases
Topic: Docs & onboarding / Community
Horizon: Now (~4 months) / Next (4–12 months) / Later (12–24 months)
Why: The identification of structured requirements according to the needs of commercial customers and critical infrastructure providers. Systematic tracing and verification of requirements
Can you help with it? yes

[ntchol]

Idea: Compliance with established Reference Architectures, especially FullStackD and CENELEC
Topic: Qrisp core / Backends & interop / Docs & onboarding / Community
Horizon: Next (4–12 months)
Why: Current big European and German projects are already establishing models on how to program and manage quantum computers. If we don't align with these models, Qrisp will be overrun by the amount of other sets of tools and offers.
Can you help with it? yes

[bastibock]

I think we are directly working continously on this.
It might be hard to assign specific tasks/ issues to it. On a governance level however I fully agree.

[ntchol]

Idea: Close entanglement of Standardization and Qrisp Development/Results
Topic: Qrisp core / Backends & interop / Docs & onboarding / Community
Horizon: Next (4–12 months)
Why: Establishing Qrisp as the reference implementation of the European Standard "High-Level Programming Languages for Quantum Computing"
Can you help with it? yes

[ntchol]

Idea: Clean architecture, layered model and design patterns
Topic: Qrisp core / Backends & interop / Docs & onboarding / Community
Horizon: Next (4–12 months)
Why: Clean architecture, layered model and design patterns => self-explanatory
Can you help with it? yes

[ntchol]

Idea: Integration of external compilers (e.g. Unitary Foundation)
Topic: Qrisp core / Backends & interop / Releases / Docs & onboarding / Community / Other
Horizon: Later (12–24 months)
Why: There is a lot happening right now. Many people/researchers are placing requests to integrate their modules with Qrisp. Let's go for it :-)
Can you help with it? yes

[rainij]

In the FullStaQD project we do exactly this with the yet very new QCC compiler developed over there. Qudora will also soon support Qrisp in their SDK - this is done via QCC. On the other hand we also consider bridges to other compilers, but yet undecided. IMO for Qrisp it makes total sense to provide interfaces to other compilers (and yes, not just one). This way qrisp can concentrate on other work, like library building or providing good abstractions.

[ntchol]

Idea: Establishing a Qrisp User Community
Topic: Backends & interop / Releases / Docs & onboarding / Community / Other
Horizon: Next (4–12 months)
Why: We need a "place" to accomodate all the people that want to work with/on Qrisp but lack the ressources or are simply willing to remain "just" users.
Can you help with it? yes

[bastibock]

This sounds like it goes very much in the direction of the onboarding discussions we need.
To have a place for users, where they can quickly learn what they need.

[HazemNuseir]

Idea: A drag-and-drop visual builder for Qrisp programs, starting with small quantum oracles and exporting readable Qrisp Python code.
Topic: Docs & onboarding / Qrisp core
Horizon: Next (4–12 months)
Why: Let users assemble typed quantum registers, arithmetic, predicates, phase marking, and automatic uncomputation through high-level blocks. Showing the generated Python and a circuit preview would support onboarding, teaching, and prototyping, and could complement Quantum Oracle Sketching.
Can you help with it? yes

[bastibock]

With Quantum Oracle Sketching, do you mean the algorithm by Zhao et al?
If so, I don't immediately see the connection.

[HazemNuseir]

Thanks for pointing that out. I wasn’t referring specifically to the algorithm by Zhao et al.; I used “Quantum Oracle Sketching” too broadly.
My suggestion is a visual frontend for Qrisp, where users assemble high-level blocks for quantum registers, arithmetic, predicates, phase marking, and uncomputation, then export readable Qrisp Python code. A small oracle builder could be an initial use case, mainly for onboarding and teaching.
I don’t have a specific connection to Zhao et al.’s algorithm in mind, so I would remove that connection from the proposal.

[purva-thakre]

Idea: Refactor the entirety of the quantum arithmetic functions in qrisp
Topic: Qrisp core / Backends & interop / Releases / Docs & onboarding / Community / Other
Horizon: now + next year
Why: Quantum arithmetic functionality is a mess. Some are duplicated functions, some are defined but not used by anything, some have static and dynamic modes in different locations. We want to clean all of this up.
Can you help with it? yes

[purva-thakre]

If this is resolved by summer of next year 🤞🏾, we want to move on towards adding newer arithmetic primitives: #845. Currently, it is difficult to build new things on top of the messy foundations.

[purva-thakre]

Idea: Build the documentation infrastructure
Topic: Docs
Horizon: now + next year
Why: The documentation build is not version specific. The code blocks in the documentation are often broken. Additional details are available in #831
Can you help with it? maybe. I hate working on mostly CI issues by myself. I am hoping someone else could help with the associated tasks.

[NedislavKolev]

We can work together on it!

[HazemNuseir]

I can help in that.

[rainij]

Idea: Versioned Jasp
Topic: Qrisp core / Backends & interop / Releases
Horizon: Now (~4 months) / Next (4–12 months)
Why: The jasp dialect files are used as an interface between Qrisp and QCC. With just one version being supported and upgrade is practically not possible (QCC would need to be updated in lock-step).
Can you help with it? maybe

Some context: https://github.com/FullStaQD/qcc/tree/main/third-party/qrisp .

[rainij]

Idea: Syntax Discussion
Topic: Qrisp core / Docs & onboarding
Horizon: Unclear
Why: Qrisp has a few variations to write control flow beyond the normal pythong syntax. This leads to friction with newcomers and also casual users who don't know or have a hard time remembering the rules.
Can you help with it? maybe

One example from the QCC project where I stumbled and felt a bit uneasy while reading is this test case https://github.com/FullStaQD/qcc/blob/main/mlir/test/tools/qcc/qrisp-integration/hisepq/repetition_code.py . It took me some time to figure out the syntax and even after reading the docs last doubts remained if it really does what I want.

I knew that these syntax variations exist, but since I am a casual user it is really not so easy for me to remember the rules.

In private conversations people also mentioned this to me as a reason why they hesitate to adopt Qrisp.

I know that it is related to JAX and cannot easily be fixed. But maybe we can have a discussion on this on what to do about it.

[rainij]

For context (for people who need the context - like me), here is an AI generated table on the constructs available today:

Qrisp classical control flow (Qrisp 0.9.6)

Construct	Python equivalent	MLIR op
q_cond(pred, true_fun, false_fun, *ops)	if pred: … else: …	scf.if
q_switch(idx, [f0, f1, …], *ops) (classical idx)	branches[idx](*ops)	scf.index_switch
with control(b, ctrl_state=…, invert=…): (classical b)	if b: …	scf.if
q_fori_loop(lo, hi, body_fun, init)	for i in range(lo, hi): v = body_fun(i, v)	scf.while
q_while_loop(cond_fun, body_fun, init)	while cond_fun(v): v = body_fun(v)	scf.while
for i in jrange(start, stop):	for i in range(start, stop):	scf.while
@RUS trial function	repeat the trial until it returns True	scf.if + scf.while

For completeness: traditional python if only works for conditions which are known before the program runs ("compile time constants" in a sense). The traditional for loops has a similar restriction and leads to loop unrolling (see e.g. generated MLIR).