Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Match by attribute namespace #107

Open
alex-dixon opened this issue Aug 20, 2017 · 1 comment
Open

Match by attribute namespace #107

alex-dixon opened this issue Aug 20, 2017 · 1 comment

Comments

@alex-dixon
Copy link
Contributor

When we have attributes that share the same namespace, e.g.:

:explanation/rule
:explanation/bindings
:explanation/facts
:explanation/matches

it would be handy to match on "explanation". We do not currently allow this. For one, ":a" must be a keyword. It might get too crazy even for us if we endeavored to support a function in this slot, though it would allow dynamic type matching. That may not be possible without rewriting the rule using a macro, as I'm not sure Clara supports this directly.

We could match on attribute namespace within a rule with the syntax explanation/* by adding the necessary logic to our default fact-type function.

@alex-dixon
Copy link
Contributor Author

An alternative may be to establish a hierarchy/ancestry for namespaced keywords.

Example:

:explanation.rule/ns
:explanation.rule/name
:explanation.rule/lhs
:explanation.rule.conditions/constraint

(define [?e :rule-explanation ?explanation] 
  :- [[?explanation <- (acc/all (juxt :a v)) :from [?e :explanation.rule]]

Advantages:

  • Might be easier to implement (depends on how much we're using the ancestry data structure vs. the ancestors function, which allows an arbitrary predicate like ":explanation.*")
  • Might be more performant than converting keywords to strings etc

Disadvantages:
Not as much of a visual indication that a hierarchical match is taking place, though Clojure's idiom of "leaf" namespaced attributes containing / does provide this information

With either approach we would match on something like explanation.rule.condtions/constraint that could have 1000x more facts than the ancestors at the depth level above. If we wanted to support direct descendant matching only, a variant on the keyword + * syntax could be provided. Not clear how we could represent something like first descendants with a namespaced keyword hierarchy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant