Faces in Accel

[hanfel-dovned]

In accel, we want users to be able to reference cells just by typing in their names, rather than by importing them as dependencies via their path:

(add a1 b2)

We have a few different ideas for this, some of which require more rewriting than others, all of which are blocked on some core shrubbery advancements. Here's the one I like:

imp/accel parses text, a cord of form ':(add a1 j2 f4)', into a [(map face=@tas pith) cord], where cord now has the form ':(add a b c)' and the map looks like {%a: ~[p/our %home %accel t/a ud/1], %b: ~[p/our %home %accel t/j ud/2], %c: ~[p/our %home %accel t/f ud/4]}.

Accel creates the cell with this new formula as the code and the (map face=@tas pith) as the dependencies. imp/accel-cell then slops the vases of these dependencies, giving them their corresponding faces, and runs the code on the new vase.

We'll need to write this code parser either way. Beyond that, this solution requires minimal changes and is blocked only on imps being able to take arbitrary numbers and names of dependencies. @liam-fitzgerald I'm curious if the app/neo rewrite will unblock this.

Alternatively, we could get this working immediately if we allow for merely a stupidly long list of dependencies, as opposed to an arbitrarily long list of dependencies, using a stupidly long ++deps arm in accel-cell. How often do you have more than 26 hand-picked references in one excel formula anyway?

We can use this issue to get our other ideas down on paper too.

[hanfel-dovned]

"will the re-write allow for arbitrary numbers and names of deps?"

~hastuc-dibtux: "no, I'm of the opinion that this should probably be an overlay namespace. consider a %y overlay where you walk the children and parse the pith and make a name based on that"

[tiller-tolbus]

imp/accel parses text, a cord of form ':(add a1 j2 f4)', into a [(map face=@tas pith) cord], where cord now has the form ':(add a b c)' and the map looks like {%a: ~[p/our %home %accel t/a ud/1], %b: ~[p/our %home %accel t/j ud/2], %c: ~[p/our %home %accel t/f ud/4]}. Accel creates the cell with this new formula as the code and the (map face=@tas pith) as the dependencies. imp/accel-cell then slops the vases of these dependencies, giving them their corresponding faces, and runs the code on the new vase.

I'm not sure if needs to be done if you have the computation happening upstream anyway and we assume that all faces of the structure [letter number] are within the spreadsheet (therefore kids of the accel node)

This obviates the need for deps at the level of the top-level accel node for this computation. We can just just the aforementioned (map face=@tas pith) to find the pith that we will be resolving in our kids, and slop the corresponding faces of those piths against our subject inside of a loop.

Then when we have computed our result against that new subject, we envase the new result and place it in the /out kid of the cell that gave us the Hoon.

---

This is the design that could work, although it wouldn't be easy. Leaving for ~hanfel-dovned's notes as I discussed with him synchronously; for anyone else trying to make sense of it good luck!

accel receives %gift poke inspect stem; if source pith is either input or link, recalculate output if source pith is output, parse all cells to figure out the dependency chain

a1 is (b1 + b2) b2/output changes ream all cells, search for reference to b2 (+search-hoon-for-face), recalculate all cells for which the reference exists

b1 latest-message/home/messages/~zod f1 -> dep(latest-message/home/messages/~zod) (b1 + f1)

a1 -> b1 b1 -> c1 c1 -> a1 resubscribe loop

deptree (tree face=@tas) +(is-parent deptree c1 a1) if true, error

[hanfel-dovned]

Superseded by #30