Welcome to ascent Discussions!

[s-arash]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[StarGazerM]

Hi Arash:
I have some ideas want share and hear your inputs:
There are a recent trend in database community that they want to make database modular, for example, you can plugin different relation datastrucure, join algorithm, join optimization etc. I think BYODs is a good start towards it.
I purpose can we maybe expose the textural IR of MIR/HIR, and change current way of codegen into taking the textual mir as import and expanding it, so that other componet in Ascent can also be operated in BYODs style.
To be more concrete:

ascent! {
  foo(a, c) <-- foo(a,c),  foo(b,c);
}

can be expanded maybe into something like:

comp_mir_rule! {
   // all dynamic relation in scc
} {
   // heads & bodies
} 

And join order opt can be compiled to take in MIR text as input and generate a new MIR as out then callback to comp_rule! to reuse all other code in ascent.

I also feel like in macro design perspective, a large macro direct expanded to rust code, maybe is not as good as expanding to smaller macro def/calls? this seem can also help with macro debugging, as now we can know which detail expansion step cause error. But that seems too much changes, maybe simply expose text IR is more than enough.

Its still very vague, let me see if I can make a more concrete examples.

[s-arash]

Hi @StarGazerM. I think I vaguely understand your proposal, but more concrete examples would definitely help! It's not super clear to me how this "modularity" would be used in practice.