I took a quick glance at egraphs-good (egg) and I can see the advantage. I just wonder whether a setup like this could manage with the complexity required for fully modelling J.
For now the calculus addon pretty much manually codes every possible combination, each with its own, adhoc structure. I agree rewriting rules would be far easier to edit (and probably reason about) in a framework like egg, certainly when having the ambitious goal of creating a rewriter / optimizer / compiler for J. If this works, it could also form the basis of a rewrite of the code for 13 : 'string' and debug/tte. The problem is I don't speak Rust. I understand the basic examples, but anything further is beyond me (for now). I also have a hard time imagining how to fit all of J into a language definition using egg (e.g. verb rank, keeping track of shape, ...) . Perhaps I just need more time to absorb... I presume that if we could model J in egg in Rust, it could be compiled to a dynamic library and called via the CD FFI to work the magic on string representations. In this way, we'd profit from the alleged speed of egg, and any future improvements they might make. The egg website also lists this interesting python notebook: https://colab.research.google.com/drive/1tNOQijJqe5tw-Pk9iqd6HHb2abC5aRid?usp=sharing . I think it would be feasible to translate that into J (I've started but not finished yet). Anyway, good stuff for thought, thanks. Op vr 30 sep. 2022 om 10:14 schreef Elijah Stone <elro...@elronnd.net>: > > On Fri, 30 Sep 2022, Jan-Pieter Jacobs wrote: > > > Ideally the simplifier should be called en-route, because the derivstg and > > family (doing differentiation on string representations) call themselves all > > the time, which is why in the current version, things like 1&o. deriv 100 > > blow up. > > Ha, yes, I see. I should mention--this representation needs to be gced > periodically, otherwise it will blow up similarly. (But any symbolic > manipulator will generate a lot of garbage, and the j interpreter is quite bad > with small objects, so this is probably better than the alternative anyway.) > > > > This is, partly, what the calculus addon does. It works with atomic > > representations, which appears to be (I've nearly no CS background) a parsed > > tree structure of any J entity. > > Afaik, 'gerund' is synonymous with 'atomic representation' (glossary agrees > with me, at least). I don't think ARs are very nice to manipulate from j. > There's empirical evidence that this is the case: the calculus addon doesn't > _generate_ ARs; it generates strings, which it then parses. This sort of > stratification is no good for composability. > > > > I'd do the edge to y first, to stick with J's right to left evaluation. Even > > if we should not really care because it's a non-standardised implementation > > detail, this is the behaviour of forks at the moment. It makes a difference > > when y or x have side effects. > > I'm not talking about side effects. + was a bad example since it's > commutative; but e.g. you care a great deal about the difference between x-y > and y-x. > > > > I don't know whether this is possible, at least not with the current setup: > > deriv executes, and thus disapears, the moment it is applied to its > > arguments... > > Right--I'm suggesting something very different from the current setup. > > > > Internally, the addon already uses this identity, see e.g. here > > Yeah--just a simple example; but the idea is that you'd want to build up a > very large library of similar rewrite rules, and a succinct way of expressing > them; and that it would be easy for people to contribute to that library of > rewrite rules. > > Perhaps a conjunction like assert_eq, such that you can say 0&+ assert_eq ]. > (Or specify separately monad/dyad; specify additional facts that have to hold; > whatever.) > > -E > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
