Python CFFI bindings for CLIPS

[noxdafox]

Greetings,

few years ago, I wrote a lightweight wrapper for CLIPS API in ctypes to overcome some issues with PyCLIPS (most important a memory leak).

Lately I decided to redo the entire work using Python CFFI which is much simpler and performant. The great advantage of such approach, compared to the standard Python extensions, is the small amount of necessary boilerplate code.

This will make transitions to CLIPS 6.40/6.50 APIs much simpler.

The library borrows a lot from PyCLIPS design but differs in few ways.

• Python 2, 3 and PyPy support
• No embedded CLIPS library, use the locally installed one
• A more Pythonic API (no CamelCase functions, use of properties and generators...)
• A more modular design
• Very simple Python-to-CLIPS data conversion model
• No string commands manipulation, only the C APIs were wrapped

I was wondering if the PyCLIPS community was interested in this project and if we could, one day, merge the efforts.

I just shared the code here.

[gitttt]

I would be interested. In the best case, we would work together with @almostearthling and @ubarkai . What are your plans @almostearthling and @ubarkai ?

[almostearthling]

I think that PyCLIPS is somewhat outdated, both in terms of style and build process. Its code is delicate and prone to errors (such as memory leaks) that are quite hard to identify: sometimes such errors may even depend on CLIPS itself, and the original authors often fix them in subsequent versions of the shell and library. Unfortunately it happens sometimes that these subsequent versions introduce small quirks that undermine backwards compatibility. Because of this I'd be glad if a different approach were taken, especially if more pythonic and less depending on the exact CLIPS API. And I'd be glad to contribute as much as I can: part of the code I wrote (for instance the module map) can be used to machine-write part of the scaffolding structure of the new module - as long as the goal is to write a module that wraps the C interface of CLIPS. Some of the ideas I had for PyCLIPS 2.0 - such as removing the redundant "current environment" interface - could also be implemented in a new module rewritten from scratch.

[gitttt]

@noxdafox how complete are your bindings? What are current or inherent limitations?
How easy can they be adapted to new clips versions?

[noxdafox]

clipspy aims to be a pythonic 1to1 mapping of CLIPS C APIs.

For example, the following CLIPS C code.

templatePtr = EnvFindDeftemplate(environment, "example");
newFact = EnvCreateFact(environment, templatePtr);

theValue.type = INTEGER;
theValue.value = EnvAddLong(environment, 3);
EnvPutFactSlot(environment, newFact, "x", &theValue);

EnvAssert(environment, newFact);

Translates to clipspy like:

template = environment.find_template('example')
fact = template.new_fact()

fact['x'] = 3

fact.assertit()  # assert is a reserved word in Python

The reason for this choice was simple, I wanted to keep the design minimalistic and to leverage as much as possible the excellent Advanced Programming Guide documentation.

With this in mind, I would say that 85-90% of the CLIPS 6.30 APIs are available in clipspy. I left behind few functions and methods which seemed useless to me. All the core features are implemented and tested: environments, facts, classes, routers, functions, globals, modules and the agenda.

clipspy is also used as backend library to implement the CLIPS jupiter notebook which I've been using for quite a while in place of the old CLIPS console.

In regards of the limitations, the most important ones are documented and are a result of the limits of the C APIs. CLIPS 6.32 fixes several of them which I reported to the engine author and I believe CLIPS 6.40 brings some significant improvement in that direction.

I plan to start migrating to CLIPS 6.40 not too far in the future. It will require a significant amount of time as the new version changed the APIs quite a lot (few changes were driven by the development of clipspy). Nevertheless, as CLIPS 6.40 does not bring any improvement for the end user, I don't think is such an urgent task.