noname needs a solid stdlib for the users to build their projects.
Building a stdlib itself is also a proof of the usability of the language itself.
To port the circomlib, one obvious hurdle we are facing is its lack of non-deterministic functions, aka hint.
We were trying to create builtins instead to avoid the under-constraint bugs from hints.
Builtins are faster and safer, but difficult to cover all the use cases. The users have to modify the compiler in order to make a builtin to support their own needs, which is difficult in practice as well.
So we would need to gauge these aspects and find a strategy to make noname practical.
Transpile circomlib to noname
Redoing the circomlib in noname could take a while. If we can build a transpiler to convert circomlib or any circuits written in circom, noname can quickly take advantage of the circom ecosystem.
To make this something feasible to achieve, one language feature that noname needs to have is the hint function.
circom support the non-deterministic without delimiting a non-deterministic block. It detects whether the expression can be translated to constraints or not, based on checking whether a folded arithmetic expressions (conceptually similar to computed type being propagated in noname) is non-deterministic or not.
Here are some quick notes about how circom works internally to support hint in full DSL.
The questions are
Does noname want to support the hint this way? It is nice to seamlessly to express the non deterministic calculations without obvious delimiting unless the use of <-- to bypass the constraint warning. But intuitively, I think expressing both the deterministic and non-deterministic at the same place without delimiting blocks, like what cairo do with %hint code%, actually makes it even more difficult to which portions are under-constrained.
Can transpiling the circomlib speed up the porting process? I think the major work is not about translating the circom code, but instead it is more about understanding how these circuits work. Even we can transpile the circomlib to noname, it is likely we still need to spend quite amount of time testing and reviewing the transpiled code.
Reuse libraries via Circ
Another idea is to see if there is a way to call circom or other front end languages through circ.
This seems to be more reliable and generating more impacts than transpile technique in a long run, but require both languages to be compiled to circ IR.
Because it is based on SMT IR, it has more chances to take advantage of the SMT researches and tooling ecosystem. So eventually there might solutions to safeguard the non deterministic calculations (out of circuit).
To do this, we need to add noname as a front end. this is actually beneficial as well, because it help increase exposure of noname.
This can be also suitable as an internship project than circom transpilation which requires non-deterministic functions which noname doesn't support at the moment.
About supporting cross language calls, if we could do this with z# or zokrate, then it should work with circom as well
Maybe we could do a quick prototype like the
circify noname code to IR
compile zsharp to IR (interesting to know that zsharp also support hint functions)
translate calling zsharp in noname code to IR wiring
convert to r1cs
The other outcomes of this circ experiement could help noname determine whether it should migrate its backend to circ backend.
(note that the latest version of circ doesn't have circom as a frontend)
Builtins and Hint
The feature grow of builtins can't scale for developer community as hint function can.
atm, it is hard to estimate how many builtins are needed, and can it adopt to various complexity for different use cases, how much time are needed to build them all.
atm, builtin can't call other native stdlib.
So it seems practically we need both builtins and hint feature to cover cases that can't be covered by merely builtins, in order to make the language creative for experimenting with new ideas, while maximizing its safety considerations.
a Balance
If the way circom expresses the non-deterministic calculations are dangerous to oversee the potential under-constraint issues, is it better to follow the way of noir or cairo to enable these out of circuit calculations?
a Hint block seems to be easier to implement and isolate from deterministic calculations. I think intuitively it is easier to review the non-deterministic logic by making it clear about boundary of these two calculation category syntactically.
Enabling the hint functions in a block could also align with the potential integration with circ, such as writing the hint function in any languages that are supported by circ. So the hint block could act as a tunnel to call circuits and just hint functions in other languages.