Basic interface for bottom-up search

[THinnerichs]

• Make iterators work with the @programiterator macro
• Make work with UniformTrees
• Address to include types
• Test with grammars that have multiple types
• Fix cases with arity>1
• Review interface: naming? Are all types necessary? Is the combine-stage state info needed? If so, where?
• Test case where some programs are not added to the bank, e.g. observational equivalence.

[THinnerichs]

• Make iterators work with the @programiterator macro:

julia> @programiterator MyBU(bank) <: BottomUpIterator
MyBU

julia> iter = MyBU(g, :Int, nothing; max_depth=5)
MyBU(GenericSolver(1: Int = 1
2: Int = 2
3: Int = Int + Int
, SolverState(hole[Bool[1, 1, 1]], Set{AbstractLocalConstraint}(), true), DataStructures.PriorityQueue{AbstractLocalConstraint, Int64, Base.Order.ForwardOrdering}(), nothing, false, 9223372036854775807, 5), nothing)

julia> progs = Set(Iterators.take(iter, 6))
ERROR: setfield!: immutable struct of type MyBU cannot be changed

[sebdumancic]

BU doesn't yet work with UniformTrees, but it should be easy to get there now.

Secondly, what was the conclusion: do we want to keep @programiterator to move to a more julian way with interfaces?

If we stay with the macro, can it switch to mutable structure? Because that is important for bottom-up search.

[codecov]

Codecov Report

Attention: Patch coverage is 82.72727% with 19 lines in your changes missing coverage. Please review.

Project coverage is 74.83%. Comparing base (7af0f7e) to head (8f24ef2).

Files with missing lines	Patch %	Lines
src/bottom_up_iterator.jl	82.72%	19 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #139      +/-   ##
==========================================
+ Coverage   72.94%   74.83%   +1.89%     
==========================================
  Files          19       20       +1     
  Lines         669      779     +110     
==========================================
+ Hits          488      583      +95     
- Misses        181      196      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sebdumancic]

Any suggestions for the interface function names? Especially the ones that manipulate BottomUpState, they are very uninspired and potentially uninformative.

[ReubenJ]

We can remove the mutable keyword for BUS iterators if we switch the interface slightly. What if we remove create_bank! (that can be done in the iterator's constructor, removing the need for mutability), and rename populate_bank! -> initialize_bank (it could empty! the bank and add primitives)?

[ReubenJ]

Secondly, what was the conclusion: do we want to keep @programiterator to move to a more julian way with interfaces?

I think the conclusion was to keep it for now. The interface approach will be nice eventually, but it'll take some work.

If we stay with the macro, can it switch to mutable structure? Because that is important for bottom-up search.

As far as I can see, it isn't important. Mutating the items in the bank does not require mutability of the structure. The only reason why it's needed now is because of the iter.bank = ... assignment in create_bank!.

[ReubenJ]

Either way, I just noticed we have support for mutable structs with the @programiterator macro.

[ReubenJ]

• Make iterators work with the @programiterator macro:

See the latest commit: this works now. I updated the example BU iterator in the tests to use @programiterator now too.

[sebdumancic]

We can remove the mutable keyword for BUS iterators if we switch the interface slightly. What if we remove create_bank! (that can be done in the iterator's constructor, removing the need for mutability), and rename populate_bank! -> initialize_bank (it could empty! the bank and add primitives)?

This actually makes more sense than the original design. I somehow convinced myself that the original design could be more type stable.

[ReubenJ]

We can get rid of the current_uniform_iterator::Union{UniformIterator,Nothing} field in the GenericBUState (it can live in the solver), but I'm pushing now as tests pass

[ReubenJ]

We also assume grammars with a single type, there is a TODO in there mentioning the change needed, but addressing will need to include this too