I am calling that maybe we can achieve the followings:
- freezing the input-output interface
- determining the granularity of lib function exposal
by using rust traits
For example, we can define the following traits
pub trait QlangFrontend {
fn query_str_2_ir(q: str) -> IR
...
}
pub trait Optimizer {
fn optimize(Input) -> Output
...
}
to bound the end-2-end behavior of our code. As an example, Input can be defined by {IR, cost-model, capability, acc-model, blah}, Output can be defined by DAG{operators, acc, cost, blah}.
Later if we want to modify Input/Output, we can redefine the Input and Output struct (or trait func signature) without messing up with
- function accessibility for lib users
- developer's view of current code status
And we implement the major algorithm by implementing the trait.
impl Optimizer for CurrentMethod {
fn optimize(Input) -> Output {
candidate_set = generate_candidate(Input.query);
selected-one = pick_one(candidate_set, Input.cost_model);
// so on and so forth, all internal logic that a user does not need to see is put here
return selected-one
}
}
The whole point is that we
- First define what are we exposing to users / developers
- Sketch out different layers of control (with rust
trait or some other stuffs)
- Migrate our code into the new framework.
We can add different layers of control. Say if we want to add different candidate generation algorithms (basically different replacement strategies), we can choose to
- make
generate_candidate a trait method as well, or
- let
generate_candidate take StrategySet as an argument
Disclaimer: This is my personal coding habit, may not be very good. I am proposing simply because I feel this may solve our problem. Please take this issue with a grain of salt.
Sidenote: I am proposing this for a second reason - I still want to implement freely pluggable optimization pass to ASAPPlanner, as articulated in issue #430, and this design allows me to do so by separately implement the Optimizer trait.
I am calling that maybe we can achieve the followings:
by using rust traits
For example, we can define the following traits
to bound the end-2-end behavior of our code. As an example,
Inputcan be defined by{IR, cost-model, capability, acc-model, blah},Outputcan be defined byDAG{operators, acc, cost, blah}.Later if we want to modify Input/Output, we can redefine the
InputandOutputstruct (or trait func signature) without messing up withAnd we implement the major algorithm by implementing the trait.
The whole point is that we
traitor some other stuffs)We can add different layers of control. Say if we want to add different candidate generation algorithms (basically different replacement strategies), we can choose to
generate_candidatea trait method as well, orgenerate_candidatetakeStrategySetas an argumentDisclaimer: This is my personal coding habit, may not be very good. I am proposing simply because I feel this may solve our problem. Please take this issue with a grain of salt.
Sidenote: I am proposing this for a second reason - I still want to implement freely pluggable optimization pass to ASAPPlanner, as articulated in issue #430, and this design allows me to do so by separately implement the
Optimizertrait.