This is pretty cool. In FP there's a pattern called "functional core, imperative shell" [0]; here, you can build your "functional core" in Haskell and your imperative shell in a language which - depending on your preferences, some might say - is a little more suitable for building an imperative shell. Because it uses JSON as the "wire format" between the two languages, you can then easily build out a different imperative shell for whichever platforms you want to support.<p>[0] <a href="https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell" rel="nofollow">https://www.destroyallsoftware.com/screencasts/catalog/funct...</a>
I’ve done something like this before to call Haskell from C++ (in [0]), so that I could build my GUI using Qt. It worked pretty well, except that I ran into various difficult-to-resolve linking problems on both Windows and Linux. After a year or two of trying to maintain it, I gave up and switched to a protocol where both sides pass JSON over stdin/stdout. This particular piece of software doesn’t require a huge amount of communication or shared data, so it works well enough.<p>The really nice thing about the original interop code, though, is that GHC’s new WASM backend uses essentially the same foreign function interface to export functions to JavaScript. So with only some minor modifications, I was able to get the same program working on a webpage [1], which I think is pretty cool.<p>[0] <a href="https://github.com/bradrn/brassica">https://github.com/bradrn/brassica</a>, and see in particular the old version of <a href="https://github.com/bradrn/brassica/blob/93d4353c5736018ec0944433d044ce6c4dc3ba3b/ARCHITECTURE.md">https://github.com/bradrn/brassica/blob/93d4353c5736018ec094...</a><p>[1] At the risk of DDOS’ing my poor little home server: <a href="https://bradrn.com/brassica/" rel="nofollow">https://bradrn.com/brassica/</a>
I've been doing similar things with Swift and Racket:<p>* <a href="https://defn.io/2023/03/19/racketfest-talk-2023/" rel="nofollow">https://defn.io/2023/03/19/racketfest-talk-2023/</a><p>* <a href="https://defn.io/2023/02/04/racket-foreign-callouts-to-swift/" rel="nofollow">https://defn.io/2023/02/04/racket-foreign-callouts-to-swift/</a><p>I also started out using JSON to exchange data between the languages, but eventually wiring everything manually became an annoyance so I came up with a little Racket DSL[1] that automatically serializes and deserializes between the two languages (at runtime in Racket & using code generation in Swift). So far, I've built two apps with this approach, and I think it's great:<p>* <a href="https://github.com/Bogdanp/Franz">https://github.com/Bogdanp/Franz</a> (macOS, Windows, Linux)<p>* <a href="https://github.com/Bogdanp/remember">https://github.com/Bogdanp/remember</a> (macOS, iOS)<p>[1]: <a href="https://github.com/bogdanp/noise">https://github.com/bogdanp/noise</a>
There's really no need to make an unsafe temporary allocation for a simple type like Int. You can just assign it a value, and if you only need it once, just pass it through with &. For example:<p><pre><code> var size = buf_size
c_birthday(rawPtr.baseAddress, data_len, res_ptr.baseAddress, &size)
</code></pre>
In this case, since you know your size is fixed, and it's actually quite large (1 MB) it is never going to fit on the stack anyways. So there is no need to use a function that will try to do that: just use Array's init(unsafeUninitializedCapacity:initializingWith:) initializer instead, and you will bridge it into Swift's lifetime management without having to do the whole closure dance. Finally, since your API is unlikely to modify the buffer you pass it in, try using withUnsafeBytes instead of withUnsafeMutableBytes (and correctly annotating the pointer with const in your bridge).
The article doesn't really explain the approach taken, to serialize data at the function call boundary.<p>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).<p>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.<p>Haskell also supports a range of C-ABI annotations, but that's on the Haskell language side, likely invisible to Swift.<p>A super-helpful contribution would be to see what range of types bridge without annotations and what additional types can be handled with annotations.<p>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!<p>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:<p><a href="https://github.com/nanotech/swift-haskell-tutorial/">https://github.com/nanotech/swift-haskell-tutorial/</a>