All struct fields should be (concretely) typed (potentially with a type parameter) [$200]
Opened this issue · 6 comments
Bug bounty logistic details (click to expand)
To claim exclusive time to work on this bounty either post a comment here or message skrastanov@umass.edu with:
- your name
- github username
- (optional) a brief list of previous pertinent projects you have engaged in
Currently the project is claimed by no one until ....
If you want to, you can work on this project without making a claim, however claims are encouraged to give you and other contributors peace of mind. Whoever has made a claim takes precedence when solutions are considered.
You can always propose your own funded project, if you would like to contribute something of value that is not yet covered by an official bounty.
Project: All struct fields should be (concretely) typed (potentially with a type parameter) [$200]
Many of the symbolic types in this library are rather clumsily defined, without much attention being paid to the types of their fields. The goal of this bounty is to specify them and parameterize them as much as possible and reasonable, in preparation for next steps like the use of sum types and Unityper.jl. This forum discussion might provide useful background.
Required skills: Understanding of Symbolics.jl and Julia's type system
Reviewer: Stefan Krastanov
Duration: 1 month
Payout procedure:
The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.
@Krastanov can i take this?
Hi, Rohit! Do you have past experience with the julia language? This is a somewhat idiomatic topic that would be easy for someone knowing the language, but not obvious otherwise.
Is someone working on this? If not, I would like to take a stab at this.
Pardon the slow response, last week was a summer workshop. This one is indeed still open and unclaimed. A couple of notes though:
- I have a review backlog from last week so I might be a bit slow to provide reviews
- This particular bounty might suffer from frequent merge conflicts as it is pretty invasive
- This one is a bit ill defined, but the goal here is to avoid underspecified types so future work that moves these structures to an "abstract data type" / "sum type" framework is easier
Hey @Krastanov would it make sense to roll this issue into actually migrating the all the QuantumSymbolics.jl types to an algebraic data type library? I recently experimented with migrating SymbolicUtils.jl to Moshi.jl in the branch here JuliaSymbolics/SymbolicUtils.jl#676 and I think the approach taken to ADTs in Moshi.jl is actually pretty elegant and seems to be quite performant.
I would be happy to take this task on, especially since changes here would already be necessary to support my proposed breaking changes to QuantumInterface.jl in qojulia/QuantumInterface.jl#26 (gentle reminder about responding that issue at some point!). I also started playing around with this library a bit recently as I have some aspirations to teach it support for evaluating various special case closed forms of BCH which are necessary for rotating frame transformations in optical systems.
Hi, Akira! Long-term moving to Moshi does make a lot of sense. I am a bit worried about being early adopters though. I know that Roger and the Symbolics.jl folks are generally interested in this happening and I am very please to see that you are already working in that direction. If that PR of yours gets merged, I would indeed like to assign this bounty to you -- however let's first wait to see how JuliaSymbolics/SymbolicUtils.jl#676 goes.