Distinguish:
1. Notional function (f+)
2. Monadic application of a function (m+, conjugate)
3. Dyadic application of a function (d+, add)
Semantically, 2 and 3 are distinct from each other; but j puns them. (And 1
needs to be distinguished to bridge the gap with j semantics.)
The j -@:% is an application of d@: to f- and f%. If you take the derived
verb and apply it (I have a special 'apply' node), cf -@:% y, you can have a
rewrite rule matching (apply (d@: fu fv) y) -> (du y (mv y)). At some point
this needs to be more sophisticated than simple rewrite rules, when you go to
substitute and parse in an explicit definition (or even to substitute du for
fu), but that is par for the course; it can still be treated uniformly.
Re ambivalent verbs: usually the user will have a particular valence in mind
and can specify that. But if you care: split the verb into monadic/dyadic
cases, apply to symbolic arguments, simplify, and then restore if necessary to
round-trip.
in + + + + +, all +'s would collapse to a single enode
Why?
On Fri, 7 Oct 2022, Jan-Pieter Jacobs wrote:
Dear all,
After recent discussion of the math/calculus addon, I started playing
around with what could become a symbolic toolkit for J, which could in turn
serve as a backend for other projects, like future versions of the
math/calculus addon, explicit-to-tacit and vice versa, etc. It should thus
remain as agnostic of verb meaning as possible.
Current status
--------------------
I started out implementing egraphs as it looked like a good idea (you can
find my progress here: https://github.com/jpjacobs/general_sym). It is
based on this colab notebook I've found:
https://colab.research.google.com/drive/1tNOQijJqe5tw-Pk9iqd6HHb2abC5aRid?usp=sharing#scrollTo=4YJ14dN1awEA.
I've gotten so far that I can convert AR's of forks and hooks into an
egraph structure, with place-holder arguments. For now, only named and
primitive components are allowed, no derived verbs resulting from applying
adverbs/conjunctions. I chose to work on AR's since all parts of speech
have an AR, and they are already conveniently parsed for recursive
treatment (discovered through my dabblings in math/calculus). My idea was
that the egraph should ignore the meaning of each individual part of
speech, only taking into account syntax. The meaning and equivalences would
then be handled by the rewrite rules applied on this egraph structure.
Perhaps easier to show than to explain:
install'github:jpjacobs/general_sym'
installed: jpjacobs/general_sym master into folder: general/sym
load'general/sym'
eg=:sym''
3 add__eg ((!+#*%+) arofu__eg)
5
en__eg
┌───┬───┐
│y::│ │
├───┼───┤
│+ │0 │
├───┼───┤
│* │0 │
├───┼───┤
│% │2 1│
├───┼───┤
│# │1 3│
├───┼───┤
│! │0 4│
└───┴───┘
The above creates an empty graph, adds the (nonsensical) train (!+#*%+) as a
monad (x=3) and shows the resulting enodes in the egraph, with y:: being
what I came up with as implied argument. You can see that + is added only
once, because it was noticed by adden that it was already present, and
applied to the same arguments, when found the second time. I thought x::,
y::, u:: and v:: were nice, since they are syntactically recognised as J
words (by e.g. ;:), but not yet used (others I'd have in mind for later are
d:: and D:: for deriv and pderiv). The first column shows the arguments,
verbs, the second column their argument references; the third I added so
you can easily see where the argument references point to. For instance, !
takes as arguments eclassid 0, i.e. y:: and eclassid 5, with 5 being the
result of # applied between arguments 4 and 3, and so on. The same works
for dyads (try x=4), NVV forks and capped forks. The interface should be
adapted to be more user-friendly but it's just a POC at the moment.
At the moment, enodes (in en__eg) without arguments (i.e. leafs) are nouns;
verbs are enodes with 1 (monads) and 2 (dyads) arguments. The numbers
listed as arguments are , in egraph terminology, called eclassid, and point
to classes containing enodes that all represent the same result when
executed. For now, eclasses are all singleton sets of enodes, as no
rewrites can be done yet.
Now I tried adding conjunctions and adverbs in the mix and came to the
conclusion that my approach runs into troubles:
To know how arguments are applied to verbs, I would need to interpret the
conjunctions (something I would have prefered to leave up to the rewriting
rules to implement).
Treating applied conjunctions as opaque, monolithic blocks, is clearly not
an option (as you then can't influence anything in its arguments, e.g.
-@-@-@- could not be reduced to ]).
An idea that at first sight seems to make sense is to give operators up to
4 arguments, up to 2 for the arguments of the operator (u/v) and upto 2 for
the generated verb, but that breaks down on operators generating operators
(e.g. 2 : '') and nouns (e.g. b. 0).
Treating the verbs on a higher level, i.e. without caring (yet) about nouns
to serve as verb arguments,crossed my mind. However, this does not let one
distinguish for instance which instance in the compound verb the enode
refers to. e.g. in + + + + +, all +'s would collapse to a single enode, and
it gets worse when they are not all at the same level.
Interpreting adverbs and conjunctions and applying arguments to verbs
directly, thereby removing the need for storing the conjunctions and
adverbs sounds fine for simple operators like @, & and family, but soon
gets quite difficult to imagine with operators like /. or ;. .
A last thing I wonder about is how to handle ambivalent verbs. Now I'm
either adding monads, or dyads, but have no way of indicating x:: might or
not be present. For instance, (#~ {."1) is useful for selecting by 0/1 in
the first column of y, but can also be used to filter from x based on y.
The same holds for (/: {."1).
So, who would have a suggestion as to how to represent operators in this
kind of framework? Any guidance would be welcome. I could go on
implementing all other machinery to do rewrites, but I feel I'd need to
have the basic representation right to start with.
Thanks,
Jan-Pieter
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
