API calling conventions for Prolog and other kind of, non Prolog, clients

Discussion
1

Hello,

I am wondering how to present an API to a non-prolog language, say via messaging, or perhaps via an engine.

Prolog has unique features such as logic variables, binding, non-determinism and a related (possible) trail of choice points – which must be “mangled” into something reasonable for non-prolog clients and calls.

I am sure this has been done many times – are there any guidelines how to name and structure such an “external” API …

comments are most appreciated,

Dan

2

You can probably start by looking at the C API for SWI-Prolog: SWI-Prolog -- Foreign Language Interface

C can call Prolog predicates, providing both a query interface and an interface to extract multiple solutions from a non-deterministic Prolog predicate.

etc

On the other end of the spectrum you’ve got Pengines: section('packages/pengines.html')

There are things in between but a) they are documented, too, and b) maybe that’s good enough for a start.

1 Like
3

thanks, good idea

Just read the section on calling Prolog from C, and its pretty impenetrable for me … the api seems to solve all kind of problems which are not explained in the documentation.

Also the interface seems fragmented e.g. the example uses a call not described in this section (PL_new_term_refs) and its use is pretty unclear to me at this stage – also reading what it does in a different section doesn’t make it clearer to me.

I will need to try this out to try to understand what is going on here

https://www.swi-prolog.org/pldoc/man?section=calling-prolog-from-c

4

What languages are you experienced with @grossdan ? I am quite familiar with C and so it makes sense to me although it does feel arcane. I much prefer the C++ wrapper of the C API with the caveat that not everything is available in C++ [unless that changed since I last checked] and so the C layer is still needed. With C++ you can simply create PlTerm objects and work on them, etc.

5

Thanks,

My intent is to provide an API that at first is not language specific, via some kind of messaging, and then, perhaps, in a language specific way, to allow tight, non messaging, integration.

Although, I decided that a first step I want to get a Prolog API worked out for (swi) Prolog clients.

This in itself is non-trivial and requires a lot of considering to create a easy to use a meaningful programmable interface.

For example, should for an API call a goal/predicate always succeed but return an error code – such as done, say, in Erlang. Or, when should a predicate be allowed to fail.

When should exceptions be used and for what purpose.

When should a predicate return with or without choice points, and what about engines and yield as a packaging mechanism and when its best used and how to deal with multi-level transactions.

There should really be a book about the design of Prolog APIs, since it is quite different to conventional API design.

Dan

6

I use such a messaging API myself but only use semi-deterministic calls. I suspect with care you may be able to embed non-determinism in the API. Unsafe illustration:

api :-
   receive(Message)
   call(Message), send(Message), 
   api.

receive/1 and send/1 are (Prolog-)deterministic network operations that somehow transfer Prolog terms.

If first you pass something that decodes as member(A, [1,2,3]), A will be unified with 1, member(1, [1,2,3]) is passed back. Next you send ‘fail’. call(fail) fails, Prolog backtracks to the previous call, unifies to member(2, [1,2,3]) and that is sent. (In this context, ‘fail’ means send me the next solution to my previous predicate.)

This illustrates how choicepoints can be part of the API, but there are more details to handle to fully manage what happens. (And also, you don’t want unrestricted terms allowed in and just passed to call/1.)