refactor: allow builder to interact with schema parser

[ivokub]

In the upcoming fake-API for field emulation branch I have implemented a wrapper for frontend.Builder which initialises the variables in the circuit witness. The builder also needs to modify the parsed schema (for example, we need a native element for every limb). For that, the LeafHandler now takes as input *schema.Field which it can modify in-place.

I think this PR may not be optimal. Will try to rebase fake-API branch on top of this one to see how it would be used in practice.

[gbotrel]

looks OK to me, not sure where this is going but doesn't look like to be introducing any regressions 👍

// VariableCount returns the number of native elements required to represent
 	// the given reflected type as a witness.
 	VariableCount(reflect.Type) int

Don't understand why this is in Builder interface.

[ivokub]

looks OK to me, not sure where this is going but doesn't look like to be introducing any regressions 👍

Just in case on how I would be using it. When I have defined variables in a circuit as type frontend.Variable (for compatibility purposes), but in practice them with nonnative.Elements, then I need to modify the schema field in-place in Builder.Add{Public/Secret}Variable method. See for example https://github.com/ConsenSys/gnark/blob/1fcebc0dcae8a0d7f06c9efe869834141cdc94be/std/math/nonnative/api.go#L62. I'm modifying in-place the schema field from Leaf type to Slice type to account that nonnative element needs several variables for storing the limb values.

// VariableCount returns the number of native elements required to represent
 	// the given reflected type as a witness.
 	VariableCount(reflect.Type) int

Don't understand why this is in Builder interface.

So, if I wrap the native builder (r1cs or scs) for using non-native field emulation (nonnative.Builder), then I need several native elements/circuit variables to represent nonnative elements. Currently compiler runs schema parser in two rounds. In first round to get number of (public/secret) wires and to shift the wire IDs correctly when initialising variable in second round. I didn't see another nice option to count the number of variables properly otherwise.

For example usage, see https://github.com/ConsenSys/gnark/blob/1fcebc0dcae8a0d7f06c9efe869834141cdc94be/std/math/nonnative/api.go#L37

Or actually, maybe I could do without Builder.VariableCount, but then I would have to compute the wire IDs lazily or somehow remove the necessary shifting for private variables?
I can probably figure it out but don't know if it makes sense. What do you think?

[gbotrel]

VariableCount is fine, this is not a user-facing API, so it's OK if we end up refactoring in the future 👍

[ivokub]

VariableCount is fine, this is not a user-facing API, so it's OK if we end up refactoring in the future 👍

👍. But I slept on it over the weekend and it may not cover all possible use cases in field emulation. I'll try before merging.