Lab notes #006 Categories redux

A good part of the week was spent reading and watching talks on "The  simple essence of automatic differentiation". I got the gist the first go around but much of the details were opaque to me. Reading it this second time around and actually working through the examples helped with the understanding.

Specifically that both fork and join are a type of composition that represents a function, but join requires a default "add" function to finalize the combination. presumable that's why there is the constraint on the co-Cartesian type to work on additive types.

It's clear to me that once you have the category representation of the code, the class instances of the closed cartesian category implement the specific function-like code that you want. It even seems clear how to execute the intermediate representation of categories, but what's still unclear to me is how you get to the intermediate representation of categories, and how to come up with the class instance that has the behavior that you want.

I'm hoping that this line of attack is fruitful for the query engine. An interesting experiment would be to implement bottom up resolution, but with incremental evaluation compiled. Does that beat a non-incremental implementation of magic-sets?

The work on the database is still on the transactor. It is coming along, though there had to be some rework due to how I had segmented the ownership of a key. When the processing of data gets to a lower level where the data is more fundamental, it makes sense to just copy it, so that lifetimes from borrows doesn't trickle all the way up a data structure.

Right now, the work is just working through the details. How are entity and attribute fields stored? It makes sense that the entity field is just an internally generated ID, like a UUID, but what about attributes? They also have names. So is the attribute name stored as a value, and that fact had an entity id that's referenced in the attribute field?

The expansion of the transaction data in the talks doesn't make sense until you realize a transformation needs to happen to make entering the data more ergonomic. Users want to enter the data like a heirarchy, like GraphQL inserts, but the database wants it in a flat list of datoms with references.