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 ♡
::
::
::
::
::
::
::
::
::
::
::
::
::
::