feature: move the QASM export to dedicated module

[skushagra]

Describe the feature you'd like
I think it would be a good idea to move the QASM export(and import) to a dedicated seprated module of its own or a sub module of a bigger exporter module which would support multiple types of standardized exports.

How would this feature be used? Please describe.
The function can stay as it is but the internal working can be offloaded to a seprate exporter module, allowing for a much cleaner code base

[skushagra]

@jacofeld is this a relevant feature that should be worked on?

[rmshaffer]

@skushagra I think it's a nice refactoring idea. Could you propose a brief outline (a few bullet points) of how you'd structure this change? e.g. specifically which function(s) you would propose moving, etc.

[skushagra]

Hi @rmshaffer

So here is my plan. Currently the to_ir which is the entrypoint for the conversion. My plan is to move the logic inside it and related functions to a sperate export module. I want to keep the implementation of the conversion same as it is now, I can plan any changes required in that in a later issue.

For the export module, in my opnion qasm can be one of the exported representations, in future we may have more.

In the to_ir, I will use the QasmExporter for now, but ideally I would want there to be no to_ir(or from_ir) function and exports only to be handled by explicitly calling the exporter from the clients code.

Let me know what you think about this.

[rmshaffer]

One complication I can see is that today the OpenQASM serialization logic is spread in several places - each object knows how to serialize itself. For example:

• Circuit._to_openqasm:

  amazon-braket-sdk-python/src/braket/circuits/circuit.py

  Line 1400 in a8666a1

  def _to_openqasm(

• Gate._to_openqasm:

  amazon-braket-sdk-python/src/braket/circuits/gate.py

  Line 141 in a8666a1

  def _to_openqasm(

• H(Observable)._to_openqasm:

  amazon-braket-sdk-python/src/braket/circuits/observables.py

  Line 61 in a8666a1

  def _to_openqasm(

• and quite a few others

Would the idea be to move all of this code into an export module, which knows how to serialize each of these different types of objects? My worry is that now we would have to move a bunch of internal details about each object into a centralized place, which kind of breaks the abstraction model that's currently in place where each object knows how to serialize itself.

Or perhaps you're thinking of something simpler?