Open lvella opened 3 weeks ago
Yes, please! :)
I think the simplest implementation would be to always use intermediate polynomials (which are essentially an expressions, but one that is not inlined by the condenser), and give the backend the opportunity to turn intermediate columns into witness columns if needed.
I think the devil is in the details though:
Couldn't we make it so that there would be a simple adapter pass from a more general witgen output to an specific backend input?
I mean, only if we change witgen to output values for all intermediate columns, right? Because the backend needs these values if it decides to turn them into witness columns. It's one option, but I think it could also increase the cost of witgen.
Ah, but the adapter could also compute the values on demand from the provided witness columns. That's a good point, nice!
Users should not worry about the degree of the constraint as they write in Powdr/PIL. Especially now that we have functions that can be nested in multiple abstraction levels, which makes it hard to know what will be the final degree of a polynomial.
Which is related to making both snippets below equivalent:
This is related because it is the compiler that should decide if it is necessary or not to introduce a new concrete column (or remove them, but I think the optimizer already does that).