an introduction to %hawk

:: :: %hawk is a programmable interface. :: it is currently vaporware... but %eyas, a prototype of it, can be installed by running |install ~dister-migrev-dolseg %eyas :: :: this file is an introduction to %hawk and its core vision. :: :: :: (double click folded lines to unfold) :: what is a homo-iconic data structure? :: a data structure which can represent Code and Data in the same format. :: example lisp languages represent both code and data as parenthetical symbolic expressions :: :: :: what is a homo-interactive interface? :: an interface which can both View and Edit some data type. :: example a textbox is a homo-interactive interface to strings. :: microsoft paint is a homo-interactive interface to .png images. :: :: :: resolving homo-iconic data structures :: you can "resolve" or "evaluate" the code parts of a homo-iconic structure into data. :: when code contains pointers, they are followed until fully resolved. :: a fully resolved homo-iconic data structure has only data left. to be fully resolvable, the pointers must not be cyclic. :: example :: unresolved (sub (add 1 2) 3) :: :: partially resolved (sub 3 3) :: :: fully resolved 0 :: :: a programmable interface :: the combination of a homo-iconic data structure with a homo-interactive interface. :: code & data in the same structure. edit & view in the same interface. :: google sheets is a programmable interface... you can... view & edit (homo-interactive) data & formulas (homo-iconic) in the same interface. :: gsheets are almost always fully resolved: each time you edit a cell, you re-resolve that cell (and others which point to it) :: :: Programmable Interfaces are Powerful and Intuitive. :: millions of non-programmers figured out gsheets on their own. and use it for real, useful work. :: you can build app-like programs in gsheets. budget trackers, data analysis, etc. :: the underlying data structure of gsheets is a 2d grid of cells. :: +$ grid (list (list ?(=data =formula))) :: :: trees > grids :: a tree is a more general data structure than a grid. :: +$ tree ?(?(=data =formula) (list tree)) :: grids can intuitively be represented by trees, but not vice versa. :: trees are better at representing hierarchy. :: hierarchy helps manage complexity. :: :: trees are better at referencing remote data. :: pointers in grids reference single cells (at best, ranges of cells). useful locally, but not flexible with large amounts of remote data. :: pointers in trees reference arbitrarily complex sub-trees. :: note: urbit's referentially transparent global scry namespace happens to be shaped like a tree... how convenient. :: :: i can make a better programmable interface than gsheets by changing the underlying data structure from "homo-iconic grid" to "homo-iconic tree". :: :: the foldable monospaced tree :: making an interface to trees is tricky because as trees become large and deeply nested they can become unwieldy. :: my solution to this is a "foldable monospaced tree" :: the lines of the monospaced file are the depth-first-search order of a tree where indentation represents depth. :: exactly like what you are currently reading. :: a node defaults to folded if its first sub-node is an empty comment :: double click this folded line to open it :: this allows simple creation of complex, bespoke, and deeply nested trees which don't become overwhelming to view or navigate. :: there were some folded nodes in the last section too. did you catch them? you can tell by the green dot next to them. :: :: it can be used as an organizational layer atop hoon code or for organizing and reading prose. :: imagine the tree of a library in this format: sentences fold within paragraphs. paragraphs fold within chapters. chapters fold within parts. parts fold within books. books fold within shelves. shelves fold within libraries. :: a homo-interactive interface to foldable monospaced trees looks like a text editor which folds on indentation. :: :: an application framework :: eyas was my first attempt to use this interface to resolve "hoon formulas" in-place. :: it was an interesting start but not enough to build full applications. :: hawk completes the vision by adding these features: :: 1. handle events other than edits. (eg. clicks) ::: - events travel up the tree until matched by a handler - handlers are hoon code which resolve to another monospaced tree (or some noun which can be pretty-printed as a monospaced tree) - the resolved monospaced tree gets swapped in to the existing tree (most of the time at the node that triggered the event) :: this is very similar to how htmx works. and i love htmx. :: 2. render rich text blocks ::: - links - images - sail code (this opens up a lot) - lines that softwrap - etc :: 3. injest data into the tree via user-defined forms ::: 4. probably some other things that i haven't discovered yet ::: :: hawk should be capable of building non-trivial, bespoke programs which have simple but usable interfaces. :: these programs should be able to reference subtrees from anywhere in the scry namespace, and insert them into the document, then visually resolve the code in place. :: :: next steps :: fix the existing problems of eyas it needs to a more excellent text editor slow for large files file navigation is ugly need to be able to "narrow" to a subtree allow user-defined dotfiles (~littel-wolfur did some work on this) visualize file diffs? :: build a library for acting on trees (or whatever i end up calling the data structure bc there is already a tree type which different) :: like the ++by or ++in arms, but for my tree type. :: reference subtrees via remote scry :: implement formula-resolution and event-handling as htmx-like "swaps" :: :: this will take more than a year at current dev pace. wish us luck ♡ :: :: :: :: :: :: :: :: :: :: :: :: :: ::