Think Windows .NET calling SWI-Prolog C functions directly.
The file in the link below has Windows Interop Service wrappers for SWI-Prolog libswipl.dll.
I have not tested this; caveat emptor.
If you have ever spent time creating Windows InteropServices wrappers then you know how much work went into making this file. If it really does work it is quite the effort.
Hi. Definitely no problem in posting this, good on you for digging it up. We’re making this code available under the AGPL, even if not all the proprieties are in place yet.
This code was handed to me by the previous developer on the project, and, as you might imagine, it did keep occasionally throwing some memory management exceptions :-).
Back then, it was a lot of boilerplate for nothing, so i replaced the C# server with a python server, and it just invokes swipl with some json and swipl parses that and eventually prints result json back 
The project has since evolved, and the question of efficient two-way channel to swipl is on the table again, so at some point, maybe i will pick up the pieces…
I think GitHub - rla/node-swipl-stdio: A Node.js interface to the SWI-Prolog communicating over stdio. illustrates the tradeoffs well.
Thanks for the writeup. Also connects to mqi, contributed by @ericzinda. My overall view on this is that for low-level languages such as C and C++ embedding is a good idea. For high level languages that have extensive runtime support including garbage collection, putting an network connection in between is typically much easier to manage and native embedding only makes sense if the protocol overhead is too large.
The discussed protocols are all text based. That has the advantage that it is easier to debug and doesn’t require low-level compiled code on either side. At some point it might be worthwhile to consider a binary protocol as well as one that can optionally use a shared memory segment.