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
