Python CFFI bindings for CLIPS about pyclips

[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.