Fork me on GitHub
#clara
<
2018-06-01
>
jdt16:06:35

So thanks to all for the help so far, but unless I can solve this "if some fact insert this other fact ONCE" problem I'm about ready to throw in the towel. It's really like I want each rule firing to be sensitive to the prior rule firings in a single call to (fire-rules), but that isn't what happens.

zylox16:06:50

you absoultely are fighting the engine if you do an insert-unconditional based on an inference, but still want logical retractions. Why are you using unconditional again? i havent followed all the conversations.

jdt16:06:26

that's just one way to do it, but it wouldn't work because that rule is going to fire twice and both firings will NOT see the Derived asserted by the first firing

jdt16:06:45

So it's not even about truth maintenance so much as WHEN the LHS is evaluated

jdt16:06:35

I'm open to any reasonable way to do it, but given LHS matching those two facts I inserted, the result needs to be ONE derived.

zylox16:06:43

I guess i dont understand why you need it only inserted once and not that the final state is one in the session.

zylox16:06:59

because you are going to absolutely end up with two if you are using unconditional

jdt16:06:23

Maybe all I need to do is replace the [Fact (= ?ftype ftype)] with use of an accumulator and predicate to express the "if there is some", and fire the rule once, haven't tried that

jdt16:06:49

Can you give a sample of the merge logic?

jdt16:06:02

Oops, I see you did, I think

mikerod16:06:05

the rules don’t assume what a “duplicate” means to you or what you want to do with them. You need an extra rule to configure that yourself.

mikerod16:06:23

Example, Maybe you wanted to know how many duplicates you had

mikerod16:06:40

you could then have (defrecord Derived [ftype matches-count])

mikerod16:06:04

Then

(defrule merge-derived
  [?all <- (acc/all) :from [::derived-intermediate (= ?ftype (-> this :derived :ftype))]]
  =>
;; Merging to one, but include the count of the "duplicates" for whatever reason
  (insert! (-> ?all first :derived (assoc :matches-count (count ?all))))

jdt16:06:50

ok, digesting this, back to drawing board

mikerod17:06:38

@dave.tenny Yep, I don’t see a reason for it there

mikerod17:06:46

I didn’t use it in the merge-derived rule either

jdt18:06:25

That use of with-meta and :type is interesting to know about when doing type based dispatches.

jdt18:06:36

Interesting tip

jdt18:06:06

Anbody got an emacs cider clojure mode switch to adjust LHS condition indentation? My clauses don't seem to want to indent to the level of the prior clause.

jdt18:06:25

Rather, bindings/predicates, not the clauses.

mikerod19:06:11

I don’t have special indentation rules

mikerod19:06:20

it indents less than ideal for vectors I’d say

mikerod19:06:25

I’ve mostly just let it happen

mikerod21:06:23

@dave.tenny I agree it isn’t ideal

mikerod21:06:51

for multiline, I typically go with:

[WorkerViableJob 
    (= ?user-id user-id)
    (= ?job-type job-type)]

alex-dixon22:06:56

Clojure in general I find it helps to just give up on making lines short

alex-dixon22:06:07

Most rules I’ve written have positional syntax so everything on one line works well…joins typically line up nicely. In Clara I’d probably do the same for the same reason…try to group things vertically by joins