Hall Notes

The main significant cost of software development is the cost of untangling what the computer is doing, and or is supposed to be doing, over and over again in your head. Any way of lowering this untangling cost is extremely welcome.

-- ~sorreg-namtyv

Standard subscription management logic (ssml, pronounced smell)

Applications must provide:

• Parts of the flow
  • Subscription updates?
  • b?
• Checks for Gall to make the right decisions
  • a?
  • b?

Untangling state changes from side effects

Two phases:

1. Analyzing what changes need to be made
2. Applying those changes

Two kinds of side-effects:

1. Subscription updates (to subscribers, I presume)

• Integrated into Gall flow

2. Not subscription updates (not to subscribers-- i.e., they hear nothing)

• The products of applications of state changes

Since subscriptions are essentially queries to an app, requesting a specific part of its data/state, we can deduce subscription updates from state changes. We merely provide the logic, and Gall chains it all together.

-- ~palfun-folsup

Gall's Armory

The above Gall architecture allows cleanly separate concerns into three basic types of arms an application must define:

1. State change analysis
2. Application
3. Subscription logic

Complex apps are relieved from deciding "what do we do when x happens?" and instead focus on "x happened, how does that change our state?" and "if our state changes like y, what does that mean for subscription z?"

New Gall (Hall) Architecture

Structures

brain: application state (now named state) delta: change to application state opera: side-effect, operation, move (now named story?) query: request (to an app) for data on a specific path prize: query result rumor: change to a query result

These names are superb! They further anthropomorphize Urbit, which we have the freedom (and maybe even responsibility) to do. See ~sorreg-namtyv's quote at top. Sadly, I don't think they made it into the PR for Hall!

Queries are idempotent:

If one diligently updates the prize they received using all the rumors that are relevant to it, they will always have the same prize as if they queried for it all over again.

Arms

Hall's arms standardize interaction with the above structures, which would benefit greatly from diagrams, in my opinion (added to TODO):

++  bake  |=  {brain delta}  ^-  {brain opera}          ::  state change
++  peek  |=  {brain query}  ^-  (unit (unit prize))    ::  response to query
++  feel  |=  {query delta}  ^-  (unit rumor)           ::  ???
++  gain  |=  {prize rumor}  ^-  prize                  ::  apply rumor to prize

::  for any given brain, delta and query, the app's response to queries (peek) 
::  must be equal to result of applications of changes to query (final query)
.=  (peek brain:(bake brain delta) query)
    (gain rumor:(feel query delta) prize:(peek brain query))  :: wrong order?

This list is not exhaustive. Others include:

• ++leak: takes a ship and query and checks if the former has permission to ask for the latter.
• ++look: asyncronous reads
• ++hear: subscription updates (rumors)
• ++fail: dealing with process errors
• ++cope: dealing with transaction results
• ++pour: dealing with responses from arvo

++prep, ++poke, and ++pull continue to function as they do now.