new qasm library

[ajavadia]

The original OpenQASM2.0 library was called qelib1.inc and contained a certain number of gates.

Qiskit now has more gates, and we have (inconsistently) added some of them to that library. I think qelib1.inc should stay how it was defined in the OpenQASM paper. We should have a new one stdgates.inc that has QASM definitions for all of Qiskit's standard gates.

[1ucian0]

I can imagine that the 1 at the end of qelib1.inc was the version number. But I'm not sure. Maybe qelib2.inc?

(also, the qe probably means "quantum experience". So guess you can make a case that the extended library you are suggesting should change the name fully indeed.)

[BlakeGerard]

Hello, I am new to open source projects and am hoping to get started by learning how to work with Qiskit. Is this still an issue of concern that I may be able to work on?

[kdk]

Hi @BlakeGerard and welcome! I'd recommend taking a look at the issues labeled good first issue as a good starting point for contributing.

[HuangJunye]

What's the status on this issue and related issue #4823? Are they still on hold?

[1ucian0]

Hi @jakelishman Did #9784 closed this?

[jakelishman]

Hmm, it's not super clear tbh. We've discussed in the past that we're in a kind of problematic position now - there's quite a lot of code kicking around (not in Qiskit) that treats qelib1.inc as being the version that ships with Terra, and our OQ2 exporter still behaves as if the file contains all the extra stuff.

I'd tend towards saying "no, we haven't properly resolved this yet". That said, I think adding a new header file to Qiskit's output is going to be needlessly painful for everybody in the OQ2 exporter at this stage, but it's on my to-do list to think about this especially for the OQ3 exporter, and when I starting writing up a plan, I might meander my way to something that would be safe-ish to apply to the OQ2 exporter as well without breaking the ecosystem that parses Qiskit's output.