Implement compilation to new SBPIR with multiple machines

[alxkzmn]

These changes do not touch the interpreter. The legacy code was already returning separate machine setups in case of multiple machines, so the changes take advantage of that. The files with _legacy suffix contain unchanged legacy code.

[leolara]

So, I didn't think how was this going to interact with the DSL, so I didn't tell you about. If you have a doubt you can ask me before.

The current dsl is going to be deprecated, for a rust DSL that can read fragments of chiquito source code.

Hence, the best option for this is that the new compiler doesn't use the DSL. Manipulate the SBPIR structure directly, even if it is more code in the compiler. If it makes sense some mutable methods could be added to the SBPIR if necessary.

[alxkzmn]

Could we spec it out a bit more? I understand this as removing any "dsl" imports from the new compiler and implementing it without them, is this correct?

[leolara]

@alxkzmn yes the new compiler should not depend on this DSL, that is using as an API more than as a DSL.

We should implement in the compiler what we require from the DSL. The legacy compiler was easier to implement with the DSL, but it is not the best way to go

[alxkzmn]

Here are the updated specs:

Scope

The scope of the changes is the refactoring of the way the compiler creates a new SBPIR. Specifically, removing any code that depends on the dsl module.

Implementation

• Refactor the build function:
  

  chiquito/src/compiler/compiler.rs

  Lines 275 to 319 in 96e83dc

  	fn build(&mut self, setup: &Setup<F>, symbols: &SymTable) -> SBPIR<F, NullTraceGenerator> {
  	let mut sbpir = SBPIR::default();
  	for (machine_id, machine) in setup {
  	let sbpir_machine = circuit::<F, (), _>("circuit", |ctx| {
  	self.add_forwards(ctx, symbols, machine_id);
  	self.add_step_type_handlers(ctx, symbols, machine_id);
  	ctx.pragma_num_steps(self.config.max_steps);
  	ctx.pragma_first_step(self.mapping.get_step_type_handler(machine_id, "initial"));
  	ctx.pragma_last_step(self.mapping.get_step_type_handler(machine_id, "__padding"));
  	for state_id in machine.states() {
  	ctx.step_type_def(
  	self.mapping.get_step_type_handler(machine_id, state_id),
  	|ctx| {
  	self.add_internals(ctx, symbols, machine_id, state_id);
  	ctx.setup(|ctx| {
  	let poly_constraints =
  	self.translate_queries(symbols, setup, machine_id, state_id);
  	poly_constraints.iter().for_each(|poly| {
  	let constraint = Constraint {
  	annotation: format!("{:?}", poly),
  	expr: poly.clone(),
  	typing: Typing::AntiBooly,
  	};
  	ctx.constr(constraint);
  	});
  	});
  	ctx.wg(|_, _: ()| {})
  	},
  	);
  	}
  	ctx.trace(|_, _| {});
  	})
  	.without_trace();
  	sbpir.add_machine(machine_id, sbpir_machine);
  	}
  	sbpir
  	}

• The function should not use any of the 'dsl' features like 'circuit()' or 'CircuitContext' ('ctx').
• Instead, the function should directly construct an 'SBPIRMachine' per every machine found in the 'Setup, and put them into the new 'SBPIR'.
• Specifically, assign all the signals and create the necessary constraints for every step directly without using the 'ctx'.

[leolara]

Yes.

So, to give you some context we built the DSL with lambdas and ctx to make it look more like a DSL and more readable. But it makes the code of the DSL more complicated.

So, if you think it is too much facilities that are useful from the DSL, you could transfer it to a SBPIRBuilder (and perhaps a series of other "builder" structs), where the API is normal and not based on lambdas and ctx.

Do you think we need this?

[alxkzmn]

I think I may borrow some code that is useful but I agree that we don't need a "lambda" anymore and generally don't need the APi-like syntax.

[rutefig]

Everything looks good to me, but it is better to wait on @leolara

Looks pretty clean, great work!

[leolara]

@alxkzmn some tests that are in legacy are not in the new compiler. A part from that approved