C++ interop design

[jeaye]

I've been fleshing out some ideas on interop and researching the prior art. Namely, Ferret and Carp stand out as relevant and interesting, especially since they both take very different approaches to this. I've documented them here: https://github.com/jank-lang/jank/blob/main/DESIGN.md#interop

I'm leaning toward Ferret's approach, at least to start, since I think Carp's could always be added on after the fact. However, I'm interested in hearing what you folks think; maybe there's a third option which we should consider!

[phronmophobic]

I've been working on c ffi from clojure with my clong project. One insight is that you can split ffi into:

1. making the data types and functions in the target available to the host (and vice versa)
2. serializing data types from host types to target types (and vice versa)

A lot of ffi libraries couple 1 & 2, but it's really nice to keep them separate and have a good option for #2. I think coffi has some cool ideas for the serialization/deserialization part.

Parsing c header files is easier than C++, but being able to reify an API is powerful. It can help a lot with some of the more annoying parts of wrapping ffi libraries (eg. importing documentation, reflection, importing constants and enums).

Anyway, as long as jank provides raw access, the rest can be done in userland. It's not a bad idea to include a higher level API as a reasonable default, but there are lots of trade-offs with respect to ergonomics and performance.

[jeaye]

Hm, clong is very cool. Nice work on that! Also appreciate the link for coffi, since I hadn't seen it before. Both of these are great additions to the design discussion.

I agree that raw access is the most important; committing to a higher level API, as part of the lang, feels like it warrants more exploration in userland first. Could be that, as with much of Clojure, there ends up being no need to put it into the compiler at all.