[prototype] More classical data types

[mpharrigan]

Some ideas on how to handle the fact that for a given encoding we usually want both a quantum data type and classical data type. For example, QInt and CInt both encode mathematical integers into bits or qubits in the same way but in a circuit we want to distinguish between a quantum integer and a classical integer.

• Introduce BitEncoding abstract base class
• Each data type "has a" BitEncoding
• Shimming for backwards compatibility
• Pretty easy to make data types based purely on composition

I think it's important to have distinct objects for common quantum and classical data types e.g. QBit CBit QInt CInt. Maybe it's annoying to always have to define two classes for each BitEncoding (the quantum and classical one). You could use something like the ClassicalVersion meta-data-type in this PR. I'm worried that: right now data type compatibility is dt1 == dt2 but if we have ClassicalVersion(QInt) representing the same thing as CInt it gets complicated. Generally, I'd prioritize making the end user (quantum programmer)'s life easier with top-level quantum and classical versions of everything at the expense of the "developer" (introducer of new quantum data types) having to do some boilerplate.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[tanujkhattar]

Can you please add classical types for QGF and QGFPoly as well ? QGF is more pressing for my use case, so I'll appreciate if you can do that in this PR and merge it.