-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ocaml] generate bindings from Rust code #156
Conversation
336f5c0
to
9a47435
Compare
// ProofEvaluations<F> <-> CamlProofEvaluations<CamlF> | ||
// | ||
|
||
#[derive(Clone, ocaml::IntoValue, ocaml::FromValue, OcamlGen)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you check the generated assembly code and confirm that we're not doing extra 'deep deconstruct-reconstruct' clones due to this? If we are, lets just make the type parameter represent 'f array
instead of 'f
and deal with this on the OCaml end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're catching a potential performance regression from this PR: #121 but it looks like I made the same change for 15-wires in this PR also.
IIRC, I didn't get why the types were not clearly defined if they were always vectors.
(Also I'm a bit worried about handling Vec<F>
as a generic type parameter within ocaml-gen.)
e2e3f06
to
5265a44
Compare
had some trouble with CI, but all good now! |
…g to get rid of plookup folders
9917cc8
to
f06a224
Compare
rebased |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This lgtm in general. I'm keen to not break the existing code while the migration isn't complete yet; I've commented where you've removed derive
statements that will do so.
ec96574
to
66ccf32
Compare
make CI happy |
66ccf32
to
22e4560
Compare
The idea of this PR is to avoid writing the OCaml bindings by hand, and generate them automatically from the Rust code. (I also recorded myself going over the code a bit if that helps.)
In the end, you end up writing this kind of code (taken from MinaProtocol/mina#9525):
to generate a single OCaml file containing:
Essentially, it creates a number of macros to help derive the OCaml bindings.
#[derive(OcamlGen)]
derive macro for types. This implements theOCamlDesc
andOCamlBinding
traits.#[derive(OcamlCustomTypes)]
derive macro for custom types. This also implements theOCamlDesc
andOCamlBinding
traits.#[ocaml_gen]
attribute macro for functions, which creates a*_to_ocaml()
function returning the generated OCaml bindingThe traits it implements on types are the following ones:
Essentially, the
ocaml_binding()
function is called to generate bindings for a type, and it'll callocaml_desc()
on all of its fields (recursively). Theocaml_desc()
function is aware of the current environment (via theEnv
var), and can thus re-write types that have been renamed or relocated in some other module.In order to avoid mixing types, a
unique_id()
function is also implemented, which returns a unique id per-type (regardless of the concrete type parameters used)