@alex-dixon that’s interesting. When I’ve mentioned support for the datalog syntax before, I was only thinking of it at a syntactic level - like an alternative DSL. The one thing I wasn’t sure of in that was how the fact-type-fn would work (what would it be?). It sounds like you’re considering an approach that is a bit more integrated with the semantics of these structures. That may be a reasonable thing to do. I haven’t worked with this sort of thing enough to have any big insight. What you describe above seems like something that may be useful and reasonable to me.

@mikerod > The one thing I wasn’t sure of in that was how the fact-type-fn would work (what would it be?) Precept uses :a with a Tuple record [e a v t] (t is an incremented fact id). We use the clojure’s (derive) to associate cardinality and uniqueness with :a keywords. Clara receives the hierarchy via the :ancestors-fn option in order to be able to match on :all attributes. Every :a descends from :all so you can write conditions that will obtain across attributes (e.g. [?e :all 42]). The ancestry is also used outside Clara for maintaining e-a-v and a-v-e indexes. When facts are inserted or retracted it lets us determine their cardinality and uniqueness constraints. Based on that and the current indexes we determine whether inserts and retracts should be performed so that the schema can be adhered to, or whether an error should be thrown. Over the weekend I worked on a design that doesn’t use global vars for the indexes and ancestors hierarchy. I haven’t figured it out yet. insert! seems like the real challenge. It’s not part of the ISession protocol and only takes facts as arguments. My best guess is that we should bind a session’s indexes and ancestry to a dynamic var (like session-context) when fire rules is called on it. Then we could read from it from within an insert! implementation and update the indexes there. I think that’d require something like a LocalDatalogSession that could take these extra arguments in its constructor.

@alex-dixon this makes sense to me.

I was thinking that the :a may be the best fact type too, wasn’t sure. And good point on deriving from :all