Messaging based foreign predicate proxy

Discussion
1

Hello,

What if there exists a mirror FFI for debugging that uses messaging to communicate between a Prolog program (thread) and foreign predicate code, written in any other relevant language.

The idea is to allow debugging foreign predicate code in any development environment, side by side, while relying on messaging to communicate between Prolog and foreign code.

Once functionality is debugged the code can be loaded (almost) as-is as library is guaranteed to work – and work faster.

Can something like this be contemplated?

Edit:

Could Protobufs (or redis) be the basis for something like this – i guess the most common denominator would be best – to ensure a simple supporting library in supported foreign predicate language for the other proxy half

Dan

3

Hi @j4n_bur53

Thank you for the terminology: foreign vs. remote predicate.

But, no confusion here.

In this call for discussion, I indeed meant to “conflate” between Scenario 2 and Scenario 4, below.

This is what a proxy is [1] – one object serving as an interface to another object, typically, located elsewhere, including remotely.

There is a Scenario 4:

Scenario 4:
         +----------+-----------------------+      +-----------------+ -------_-+
         | Prolog   | Prolog FFI Proxy Half |------|  Foreign  Proxy | Foreign  |
         +----------+-----------------------+      +-----------------+----------+

I imagine that Foreign Proxy and the current FFI would have equivalent and fully interchangable interfaces.

The idea, is, I guess, analogous to RPC calls, where the client is oblivious if the called function / object is local or remote – and the Foreign code is oblivious that it’s called via a proxy foreign interface.

Now why to do that:

For a developer, it would allow creating the Foreign code against the Foreign Proxy API – in any IDE and supported language that can run in parallel to the IDE used for Prolog code.

Once development is completed, the developer can choose to switch to scenario 2 – and have the Foreign code loaded as is today.

Whether such a construction makes sense to keep as a remote “RPC” – perhaps yes – but, then all other considerations come to play including security, etc.

I guess there is also a scenario 5, for transparent Prolog to Prolog RPC calls … if one wants to create a distributed system – i guess, a ROS Prolog embedding is doing just that, although, perhaps not transparently for Prolog developers.

[1] Proxy pattern - Wikipedia

5

I understand that FFI is currently understood as an interface to an external C function that is loaded as a DLL or another kind of dynamic linked library.

However, conceptually speaking FFI could simply denotes a Foreign Function Interface – any kind of foreign function via any kind of interface.

All, i am saying is that such an interface can also be envisioned as a call across a process or network.

Dan

7

Keep in mind that I am not envisioning this as a general purpose distributed programming infrastructure-- its just there to allow conveniently debugging a foreign function using in an IDE of choice for the language without needing to use the same IDE for both Prolog, and the foreign language.

Btw, this is a setup i am currently using – with WebSockets – just that i am not developing a foreign function – but interacting with a remote system via messaging. And, the remote system has its own debugger – and it works great.

Dan

10

This is a great idea.

However, my main motivation is to create a set of foreign functions via FFI – just that I want to work in a best possible dubgging environment for the language in which I would develop it in – C/C++ or Rust.

So, perhaps, a work around is to have an FFI Proxy with messaging … that can seamlessly switched to a real FFI …

Edit:

Alternatively, perhaps my musing here is a moot point and one can readily debug in both languages in, say, Eclipse – i just need to figure out how to set this up.

Dan

11

I must have missed that …

Websockets is only one way to have an external environment receive and send payload to a prolog program. I think other approaches might be better suited … such as protobuf or redis