What's the relationship between kanren and Aesara?

[majidaldo]

...so what functionality will be here, in kanren, vs what will be in aesara?

[brandonwillard]

I'm not sure I understand the question; what sort of functionality did you have in mind?

[majidaldo]

i was wondering what's so specific about these https://github.com/aesara-devs/aesara/tree/main/aesara/graph/rewriting that wouldn't go here.

(not a big deal. pfff i can't delete a question.)

[brandonwillard]

No need to delete anything; these Discussions can be about anything related to the project. It's also a good line of questioning, I just didn't know where to start without potentially leaving out the specific information you wanted.

In general, Aesara is only concerned with term rewriting for very specific types of term graphs and equational theories, and it has no "first-order" notion of relations, so there's not much that can be directly transferred from Aesara to kanren. What we're trying to do over time is develop efficient term-rewriting-specific data structures and relations for kanren so that we can replace the limited and overly-specialized machinery in Aesara. We need to do this in a way that doesn't compromise kanren's flexibility and/or make it diverge too much from the simple, standard miniKanren spec.

The efficiencies afforded by the term rewriting code in Aesara are often based on design choices that don't translate well to kanren (e.g. use of stateful/mutable objects). There probably are ways of porting most efficiency-providing Aesara approaches to kanren, but, for at least the ones I've considered, the ports aren't exactly simple (e.g. #48, #65).

Really, the reason such ports tend to be fundamentally difficult is that we need to translate non-relational concepts into relational ones, and that can have a lot of concept and design overhead. For example, something like #64 might be a big improvement for term rewriting in kanren; however, some high-level work is needed just to properly frame the approach within miniKanren, and only after that's clarified can we actually say exactly how the approach would be an improvement.

Aside from that, the domain-specific "knowledge" in Aesara (i.e. the rewrites that express tensor algebraic relations) is far too specific for this project, so there's no way of using that work here, and it basically makes up the rest of the rewrite-related material in Aesara.

[brandonwillard]

N.B. I explain some of the basic motivations behind using kanren in Aesara in the paper "miniKanren as a Tool for Symbolic Computation in Python".

[majidaldo]

thanks for the details!

We need to do this in a way that doesn't compromise kanren's flexibility and/or make it diverge too much from the simple, standard miniKanren spec.

ya i really appreciate the minimalism of minikanren. i think a design constraint should be that it should always be possible to compile bare mk.
it could be like a (higher) IR.