CLIPS port to .NET

[Theodore Neward]

I'm working in a startup in which CLIPS will be of great use; I've
been using the CodePlex port of CLIPS to .NET, and finding it OK for
prototypes, but not particularly useful for real-world work only
because of how it was ported (it's just a thin interface wrapper
around the x86-compiled native source, which means it's tied to the
x86 hardware, which is not exactly commonplace anymore in server
systems like Azure or Amazon).

I'd love to hear that a fully non-native (pure) .NET version of CLIPS
exists, but I've been hunting a while and not found one.

I'm now contemplating doing a full port to .NET, similar to what
Ernest did with Jess. Before I go down this path, I'm hoping that the
current programmers on CLIPS can drop me an email off-list (or we can
keep the conversations on-list, if you prefer) to help me get a good
idea of what the easiest path through this would be. I'd like to build
it in such a way that it keeps the original spirit and flavor of the
engine, but with a nod towards a more decoupled architecture, if
that's reasonable--in other words, instead of making it a plain-text
interface between the engine and the embedding project, do something
more along the lines of how the C interface works. (Based on what I
see of it, anyway.)

I am wide open to suggestions on better approaches, too.

Hoping that this message finds a sympathetic audience.... :-)

[Karell Ste-Marie]

Ted,

I for one have a similar need and would love to use this project as a learning opportunity.

Let me know if you need a hand - however my CLIPS skills are quite basic (for the reasons you outlined above, can't use it on most hardware).

--
--
You received this message because you are subscribed to the Google Groups "CLIPSESG" group.
To post to this group, send email to CLIP...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/CLIPSESG?hl=en

--> IF YOU NO LONGER WANT TO RECEIVE EMAIL <--
Visit this group at http://groups.google.com/group/CLIPSESG?hl=en
Click on "Edit my membership" link.
Select the "No Email" radio button.
Click the "Save these settings" button.

--> IF YOU WANT TO UNSUBSCRIBE <--
Visit this group at http://groups.google.com/group/CLIPSESG?hl=en
Sign in
Click on "Edit my membership" link.
Click the "Unsubscribe" button.
Note: This appears to be the most reliable way to unsubscribe

Alternately, send email to CLIPSESG-u...@googlegroups.com. You will receive an email which you must respond to as well to unsubscribe. Clicking the link mentioned in the unsubscribe reply does not appear to work reliably.
---
You received this message because you are subscribed to the Google Groups "CLIPSESG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clipsesg+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

------------------------------------------------------------
Karell Ste-Marie
CIO - BrainBank Inc

MCP, MCAD, MCSE, ETC

[CLIPS Support]

The primary benefit of having the code in C is that it's very fast. The drawback is no object-oriented design and access to class libraries. If I were doing a port, I'd look at the Jess and Drools source code to get a feel for the object-oriented design and then decide how you want to accomplish similar functionality in .NET and determine what should be redesigned when moving from a non-object-oriented design to an object-oriented design. The most complicated part of the design will be deciding the best way to implement the Rete algorithm. As for the API, a large portion of it is useful only if you're embedding CLIPS within a development environment. The approach used for CLIPSJNI was to develop some examples in order to determine the type of API needed to support them and also remove some of the complexity in dealing with the low level data structures used by the C API.

[Ted Neward]

The Jess source code, alas, is not open for view. I can look at Drools, but I was under the impression that it wasn’t a full Rete engine—did that change recently?

 

C’s other advantage is that it’s hugely portable and embeddable, which is part of the reason why I want to think about doing this in such a way that it would be also easily embeddable. (Portability I can’t do much about if it’s a .NET sourcebase, except to make sure that it works nicely with Mono.)

 

My thought was to build the engine such that it wouldn’t “just” take string input, but actually provide a mirror (sort of) of the C-based embeddable API. So that, for example, a .NET program could assert a fact by calling Engine.AssertFact(new FactValue(…)); or something similar. Do you think this is a wise path to take?

 

Ted Neward

Leading, Speaking, Consulting, Writing

http://www.tedneward.com

 

--

[CLIPS Support]

The current version of Drools implements Rete. I'm not sure about your qualification of a "full" rete algorithm as there are all kinds of variants in the ways rete is implemented, but I believe rete has been supported in some form for at least seven years. In addition, they've support other matching algorithms.

There's three levels of APIs you should consider supporting in order (in decreasing order of bang for the buck). The functionality of the first includes creating and managing environments, objects representation of the CLIPS primitive data types (float, integer, string, symbol, multifield, fact address, instance address, and instance name), and calling the Eval function. You can accomplish quite a bit with just this level of functionality especially with languages that allow you to easily concatenate strings without having to worry about allocating/deallocating storage. This level is what's currently supported in the CLIPSJNI.

The second level would be to mirror some of the more useful functions from the C API. As you've mentioned, the ability to create facts/instances and assign values to them. Perhaps the I/O router system. Also some of the commonly used functions such as Reset or Run which are easy to implement (but would already be covered by the first level APIs as you could call these through Eval).

The third level would be everything left over. For example, the APIs for iterating over the activations, constructs, and facts/instances. Most of these are things you'd only use if you embedding CLIPS within a development environment.

So mirror the APIs when it make sense, but try to simplify the APIs when possible and implement the most important ones first. For example, many of the C API functions have both a type and value parameter whereas your .NET API function could determine the type of the value parameter by checking its class. In addition, it should "feel" like a .NET API rather a C API with a .NET wrapper. For example, I don't think any of the C API for managing the symbol tables (such as AddSymbol) should be exposed.

[Ted Neward]

All of this is exactly what’s in line with what I’m thinking—this is good stuff, thanks.

 

By “full” rete, I meant “backwards and forwards chaining”; Drools at one point was just doing forwards-chaining, IIRC. It was a long, long time ago that I looked at it, so it’s probably not relevant anymore.

 

I want to keep the feel and flavor and implementation of CLIPS as much as possible, so that you or any other CLIPS-familiar developer could step in and use it, but yes, I want to take full advantage of OO design/approach and .NET idioms as possible. (The step after this is to make sure it works well from F#. ;-) )