oh wow I was just about to ask about dynamic rule creation

The issue I have would be that the list of conditions in the lhs (and some part of the rhs) would be based on the elements of a list that is bound with a condition

The problem is I can not seem to express it right with defrule nor the underlying code datastructure

I might be stepping too much over what the rete network does so it might be slow, but if nothing else there should be a way to look into the underying knowledge base for a set of checks the very least based on which I could bind a variable on the right hand side

but this seems like internal stuff to clara the very least

was thinking maybe having a test expression that uses a functon and perhaps some internal way of peering into the current knowledge base, based on which it would return variables

@newres I'm not sure I entirely follow your use case, but it seems possible in principle with some of the rule generation patterns described above. However, I'm not sure I'd suggest that approach if you can avoid it. It might be better to, for example, put the needed data in some structure on the left-hand side, and bind the entire structure to a variable...and then de-structure that variable on the right-hand side to get the nested structure out.

@ryanbrush The problem I would have in binding everything and move it to the right hand side is that in the current implementation I need to use the conclusion in the guard.

@ryanbrush is there a way on the lhs to reach into the current knowledge base with an expression, without resorting to unification and bindings? Basically with regular programming with some datastructure as a knowledge base the problem is pretty easily solvable, I would not mind skipping any optimizations clara provides just in a few cases.

@ryanbrush to describe the problem I have a bit better, suppose I have bound a list to the variable ?L. Based on this list I need to check x number of conditions where x is the length of that list and the conditions vary based the the list elements.

The left hand side can only see the fact it is analyzing, and previously bound variables. Unfortunately there isn't a way to dynamically peek into the memory more than that...and there isn't a way to really make that visible that will be stable, either, since the order of evaluation of each rule constraint isn't defined, and we use a mutable structure underneath that can change at any time.

Generating rules ahead of creating the session can be done, but it's not clear whether that helps much. The visibility of the LHS to the fact its evaluating and previous, explicitly bound variables in earlier constraints on the LHS is a pretty firmly build in.

But you can still bind a list or other structure in one LHS constraint, and then analyze it in a subsequent LHS constraint, if that helps.

...which includes test guards

The problem there is I do not know how I would express the fact that for all elements in that list I need a new slightly different constrained. For example suppose I have in the list 3 variables ?p1, ?p2, ?p3 I would need 3 conditions that check like [T (= ?a s) (= ?p1 p) (= b o)] [T (= ?b s) (= ?p2 p) (= c o)] [T (= ?c s) (= ?p3 p) (= d o)]

I can probably generate or write up such rules for the length of x manually if writing it for arbitary lengths is not possible

Another simpler option (which may or may not work for your needs) is to use an accumulator to match a list of all items of type T, and then analyze that list in your guard.

The accumulator might not bind anything but the result, so it just passes a list down, and you can call an arbitrarily sophisticated function in the guard to sort it out. Some documentation here: http://www.clara-rules.org/docs/accumulators/

so I could get all the values of T where the middle variable is a member of the list (In my implementation nearly everything is T, so I need to narrow some things down), than have test as a guard that pretty much checks what the conditions would do in a normal case

Yeah, that should work.

It's probably not the most idiomatic way to structure rules, but we've done things like this as well.

If you really want to get fancy you can write your own accumulator...but just grabbing everything (or just using simple filters if that works) can get you there.

is there a simple way to say that i want [T (= ?b s) (= ?pl p) (= c o)] where ?pl is a member of a list l

Yeah, you can pass ?pl to any function on the LHS after it is declared, including checks for inclusion in a list.

aha yes that would work, not sure about the efficiency but right now getting it working would be a good step

Thanks for the help! i am probably pushing clara in some really weird and unexpected ways but the docs really help

Cool. Glad I could help and good luck with your system!

and the board and the slack, thanks !