dank (Mar 20 2023 at 22:25): dank (Mar 20 2023 at 22:25):so i think my interop is about ready (which is more thorough than the previous so required a more thourough dive into some topics),
thought i'd share with you a couple of notes i've taken
might be useful for either future interops/ hosts or glue writing/ compiler changes (maybe? see first note about inconsistent layouts (flipped ret position) and second about unnamed types)
requiring multiple function from the application - via record
note from the host side it will require a different argument layout than what you used for a singular function
e.g:
single function - extern void roc__interpolateStringy_1_exposed_generic(struct RocStr *ret, struct RocStr *name)
record style - extern void roc__programForHost_1__InterpolateString_caller(struct RocStr *name, char *closure_data, struct RocStr *ret)
where both the arguments are fliped and there's a third closure_data argument (to which you'd probably pass 0 if you don't do closures)
when declaring the program functions record in the roc platform file, name the types (as), for example interpolateString : (Str -> Str) as InterpolateString, otherwise (as the time of writing this) roc doesn't really generate them.
careful what you release/ delete. in some VMs, let's say you use a builtin binding to do something, e.g Java's string constructor, you do not need at all to delete a local ref you made to it.
let the jvm take care of it. misuse will result in nasty segfaults. consult ffi docs ofc
might be obvious if you know but compile the .roc side with --no-link to compile to .o files which can then be coupled together with the host code. i messed around with --lib and linking shared libs when i didn't know about it. this is much much cleaner and better than having to carry around another shared lib
roc_panic could be tricky since it's a no return function (that is obviously not exported to the vm, so it can't do some vm stuff), but you need to propagate the crash back to the vm. one possible solution is, from the wrapper to the function that might crash, when calling the platform, put a setjump. if it indeed crashed and went on to roc_panic, longjmp from roc_panic back to the exported vm function so you could propagate it back up.
hope it'd be of use
Last updated: Jul 05 2025 at 12:14 UTC