directed experiment 1: rep_lang_playground

[mhuesch]

rep_lang_playground

background / motivation

"twisty path of experiments / prototypes"

this is the forerunner of a new dev approach for the integration of rep_lang with Holochain.

the motivation here is half to advance towards a final architecture for Neighbourhoods, and half to for me to develop the necessary mastery of Holochain required to pull off that final design.

the plan is for me to build a series of prototypes / experiments which build on each other and zig-zag towards the full "interchange" / "cultural computer".

sketch of rep_lang_playground

• [x] InterchangeEntry datatype which packages rep_lang's Expr, Type, and Value datatypes for Holochain de/serialization

  • [x] SerializedBytes can be hidden behind a Cargo feature flag

• [x] creation of a new InterchangeEntry

  • create_interchange_entry(expr: Expr, args: &[EntryHash])
  • typecheck input expr
  • dereference args (& ensure they are InterchangeEntrys)
  • typecheck the application of expr to freshnames which are bound to the Types dereferenced from args
  • invoke rep_lang interpreter on the application of expr to freshnames which are bound to the Values dereferenced from args, resulting in a Value
  • package everything up

• [x] validation of an InterchangeEntry

  • perform the above steps, compare equality on Type and Value
  • both of these are in theory undecidable. however we can perhaps work around this by assuming everyone runs the same typechecker and interpreter, and they are deterministic, and therefore will produce the same output given the same input. I think this should work but don't know yet.
  • sanitize / rewrite variable names in any InterchangeOperand closures
    • recur over an Expr with a mapping from Name to Name. create new freshnames when encountering a binding, store the correspondence. when encountering a Var (reference), look up in mapping & substitute Names.
  • we could also consider de Bruijn indices as a way to manage exposed variable names, which are now "public" via closures
  • consider/explore: how will agents validate their peers' entries? this seems to be a central & unexplored issue. programs contain arbitrary recursion and therefore cannot be guaranteed to terminate. EVM design decisions may be relevant. termination checking also a possible approach (tho may be difficult to implement).

• [x] UI (using Yew) to enable easy construction of these Entrys

  • I ended up using a terminal UI using tui (https://crates.io/crates/tui), not Yew. ran into wasm issues where Holochain hasn't expected anyone to make websocket calls to Holochain from Wasm, so there is not good library support.
  • UI for parsing/typechecking Exprs from textbox input, displaying live feedback for the user
  • given a type-checked Expr, UI for selecting compatibly-typed inputs from the DHT

• investigation of "marker/oracle" approach for incremental processing of large lists

  • consider optional forms for incremental production/consumption of large lists. this would produce a thunked list containing a marker which, when encountered by the interpreter, can be dereferenced (via some quasi-coroutine interface) from the interchange as the remaining tail of the list. this can occur ad-infinitum.
  • (tho we hope for finite lists, I don't think we can guarantee it. but because of agent-centricity, the agent will just make their own machine hot. hopefully. consider a bound on evaluation, like Gas for Ethereum, as a fallback solution).

• porting of "external" (to rep_lang) data, out of Holochain, into rep_lang

  • we'll need some sort of conversion/import ability (likely rudimentary at first)
  • this is the beginning of a key function of the interchange
  • this piece captures much of #3 and would subsume/close that issue

• exploration of fully reproducible builds / deployments

  • the popular Rust/hc/npm amalgamation is not reproducible in the way a full nix setup would be. I have reason to believe that this will go against the grain (current hc tooling), so may not be worth it. however, IMO, reproducibility is worth the investment most of the time.

sub-issues

• [x] closures contain VRefs which point to the Sto of the interpreter which originated them. this means they'll be dangling pointers for other interpreters
  • suggested solution: parameterize TermEnv over the referent (value). feed that type parameter through in Value. use that to make FlatValue contain FlatValues in the TermEnvs of its closures. change Value <-> FlatValue conversion functions accordingly.

[mhuesch]

work is already underway on https://github.com/sacredcapital/rep_interchange/tree/marker-oracle-draft

[mhuesch]

with #11 merged, this can be closed.