SWI-Prolog -- Foreign Language Interface

12 Foreign Language Interface

SWI-Prolog offers a powerful interface to C Kernighan & Ritchie, 1978. The main design objectives of the foreign language interface are flexibility and performance. A foreign predicate is a C function that has the same number of arguments as the predicate represented. C functions are provided to analyse the passed terms, convert them to basic C types as well as to instantiate arguments using unification. Non-deterministic foreign predicates are supported, providing the foreign function with a handle to control backtracking.

C can call Prolog predicates, providing both a query interface and an interface to extract multiple solutions from a non-deterministic Prolog predicate. There is no limit to the nesting of Prolog calling C, calling Prolog, etc. It is also possible to write the‘main’in C and use Prolog as an embedded logical engine.

Section Index

LogicalCaptain said (2020-09-28T20:07:13):

For a C++ interface

Take a look at this package:

A C++ interface to SWI-Prolog

C interface: Not standardized

In this discussion Jan Burse writes:

... this is one more issue that is very much neglected by the ISO core standard:

Foreign Function Interface (call-in and call-out)

For example Java, Fortran, Pascal, etc.. isn't agnostic to this. And real Prolog systems aren't aswell agnostic to this, lets look at SICStus, what concerns call-out and even call-in, you have (sorry old release 3 docs):

Mixing C and Prolog https://sicstus.sics.se/sicstus/docs/3.7.1/html/sicstus_11.html

Mixing Java and Prolog https://sicstus.sics.se/sicstus/docs/3.7.1/html/sicstus_12.html

So we have two neglected issues by the ISO core standard, multi-threading and foreign function interface, and of course all questions about the combination of both.

Nevertheless we hear "industry strength" here and then. A standard is not industry strength if it doesn't cover multi-threading and foreign function interface.

Update the reference?

I guess referencing Kernighan & Ritchie, 1978 is a bit quaint.

We are now 40 years later, at least at C17

Maybe this book should be referenced instead:

Modern C by Jens Gustedt

It is definitely larger than K&R at 408 pages, but updating C tradition seems necessary. Myself, I'm still stuck at 1990 or so.

From the preface:

In this book, we will mainly refer to C17, as defined in JTC1/SC22/WG14 [2018], but at the time of this writing some compilers don’t implement this standard completely. If you want to compile the examples in this book, you will need at least a compiler that implements most of C99. For the changes that C11 added to C99, using an emulation layer such as my macro package P99 might suffice; the package is available at http://p99.gforge.inria.fr.

It contains this warning on page 23:

- Experienced C programmers: If you already have some experience with C programming, what follows may take some getting used to or even provoke allergic reactions.

- If you happen to break out in spots when you read some of the code here, take a deep breath and try to relax, but please do not skip these pages.

A related blogpost by another author:

Modern C for C++ Peeps