The article doesn't really explain the approach taken, to serialize data at the function call boundary. Haskell supports a C API/ABI directly, as does Swift.

The article doesn't really explain the approach taken, to serialize data at the function call boundary. Haskell supports a C API/ABI directly, as does Swift. E.g., Swift String can be shared as cstring, i.e., a null-terminated byte array, with no allocations needed. Since both languages support the (per-platform) C API/ABI, that would seem to be the best option, with home-grown serialization a risk (or perhaps a fallback where necessary). In most cases, Swift simply handles the C-type without needing any special bridging. In some cases of ambiguity, you can add attributes on the C declarations to tell the Swift compiler how to handle the data and call. Haskell also supports a range of C-ABI annotations, but that's on the Haskell language side, likely invisible to Swift. A super-helpful contribution would be to see what range of types bridge without annotations and what additional types can be handled with annotations. But since the author did go to all the effort of marshaling, they must have discovered unavoidable limitations. It would be most helpful to know what those were! Edit: here's a tutorial for swift calling Haskell from 5 years ago, before the huge changes in Swift 5.9 for C/C++ interoperability: https://github.com/nanotech/swift-haskell-tutorial/ https://github.com/nanotech/swift-haskell-tutorial/