Skip to content
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

Increase type safety at the FFI boundary #30

Open
g2p opened this issue Apr 20, 2021 · 1 comment
Open

Increase type safety at the FFI boundary #30

g2p opened this issue Apr 20, 2021 · 1 comment

Comments

@g2p
Copy link
Contributor

g2p commented Apr 20, 2021

Currently there's implicit trust in the fact that OCaml<T> values are created with the right type.
OCaml::new is marked unsafe as it should, but there are plenty of "safe" wrappers that don't guarantee that we have the right OCaml type. For example, OCamlClosure doesn't have type parameters, and the various call functions use caller-chosen types.

As more complex OCaml<T> types get implemented for various T, it would be good to have these guarantees at the right boundary, so that checks are done at most once and the specializations can trust that they work with the right in-memory representation.

One way to do that would be to introduce a trait that T implements that checks that a RawOCaml is safe to parse as an OCaml<T>.

As for the ocaml! macro which generates most conversions to OCaml<T>, I don't know the overhead of using the safe interfaces every time; assuming the declarations stay well-typed here may or may not be a good idea. For now I'd like to at least ensure safe interfaces exist.

@tizoc
Copy link
Owner

tizoc commented Apr 20, 2021

Note that OCamlClosure is not exposed and only meant for internal use, but you are right, all it's functions, although not marked unsafe, are. ocaml! is the only public interface to OCaml functions.

About type-safety at the boundaries, my intention for improving this when I have time to get into it, is to generate glue code for all definitions (OCaml code from Rust definitions, and Rust code from OCaml definitions), for both composite datatypes and functions. Then on each side you will interact with this autogenerated glue code which you know is correct. That way you can get the type-checkers from both languages involved in the correctness validation at the boundaries, all at compile-time.

Right now if you make a mistake when declaring a function, struct, etc (by missing a field/parameter, or using the incorrect order), things will go wrong because there is no safeguard at compile time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants