Implementing rules

[cgrand]

Adding rules to EZ has two impacts: visible and not.

The user-visible impact is (defrule ...) (or something in this spirit) offering a way to factor code (and the experience so far proves that it's way due).

The invisible impact is that there's currently a LOT of queries which are run at each change and these queries have common parts (they can be organized as a tree and that's something I've started doing and this tree follows the structure). Using rules (well idb predicates) would allow a more natural way to structure the sharing (and also to get shared computation).

This would also allow recursive widgets (trees yay!).

[cgrand]

Each template has its own rule (I abusely use rule for idb predicate) and this rule has as many arguments as there are lexical bindings.

A template rule must use its parent rule.

I feel there's a need for a path attribute (that would mean a constructor -- skolem predicate)

[cgrand]

Some things are counterintuitive at first: name and arguments of a deftemplate are an IDB predicate and each call site to a template is in fact a derivation rule for its predicate!

[cgrand]

Trying to recap: each "template" is associated to a rule whose last argument is a path.

Assuming only x is bound so far, (x/for (and (a x y) (b y z)) body) produces:

for_q_1234(x, y, z) :- a(x, y), b(y, z).
for_body_activation_1234(x, y, z, path) :- for_activation_1234(x, p), for_q_1234(x, y, z), vector(y, z, v), conj(p, v, path).
active_components(path) :- for_body_activation_1234(x, y, z, path).

A fragment (body) with N sub templates would produce:

subtemplate1_activation(bound-vars..., path) :- fragment_activation(bound-vars..., p), conj(p, 1, path).
...
subtemplateN_activation(bound-vars..., path) :- fragment_activation(bound-vars..., p), conj(p, N, path).
active_components(path) :- subtemplate1_activation(bound-vars..., path).
...
active_components(path) :- subtemplateN_activation(bound-vars..., path).

A terminal doesn't create rules on its own : its just a terminal, it consumes data from its activation.

Last but not least, a deftemplate creates a public activation rule and each "call" to a template is going to add rules to this activation.

[cgrand]

Addenda:

1. it's easier to have the path as the first argument (and it doesn't matter as it's an implementation detail).
2. terminals do emits rules:

active_components(path) :- terminal_activation(p, bound_vars...), vector(used_vars, v), conj(p, v, path)

[cgrand]

Things are starting to fall in place again. Phew. Fragments and terminals are correctly emitting their rules. For example

  => (ez/deftemplate xoxo [] (for [(_ :user/name name)] [:h1 "hello" name]))
  => (`ez/component-path (impl/eval-rules {`xoxo #{[[] "You"]}} (ez/collect-rules xoxo)))
  #{([0 ["You"]])}

for is in progress (i.e. being actively debugged).

(Note to self: deps are not collected now, they should.)

To give some background: in the 1st prototype, components paths were computed by running many complex and wide queries and then mapping result sets to create paths. Not only this was inefficient because these big queries were sharing a lot of subqueries (so duplicated execution) but it was also hacky (in the way queries were built) and, more concerning, it was hindering expressivity in two ways:

1. no possibility to call rules (plus rules restrictions in datascript/datomic disallow one to use 2+ datasources which is a problem)
2. no possibility to have recursive templates (that is to render trees) because the hack to generate queries would mean to produce an infinity of queries.... unless you can use rules (GOTO 1).

As of today I had the first components paths computed by rules (interpreted by the nascent EZ datalog impl). It means that soon I'll be able to plug back components instantiation on it.