PeterReid

I cut out jets entirely. The programs that I anticipate having to execute are mostly simple compositions of retrieving data, storing data, transmitting packets, and cryptographic operations, so being able to do heavy computations did not seem worth the complexity. It is still early days in this project, though, so I might change my mind.

Infinite loops are covered by a general cost-tracking system. A computation begins with a certain number of ticks allocated to it, which an agent will use to weigh the CPU/storage space/network usage of what they're executing against the benefit of maintaining a relationship with the agent for whom it is executing. Infinite loops will just run down the tick counter and terminate.

I am not compiling Hoon. I have not actually learned it well yet! Since the programs involved are simple, I have mostly just been writing Nock slightly programmatically, like this: https://github.com/PeterReid/hoplight/blob/3971f7c7e45bceed9...

But I did write an abomination to make that a little easier. I am programmatically constructing a the AST here, since I have not gotten around to writing a parser.

  lett(vec![
        ("decrement", lambda(vec!["target", "possible_antecedent"],
           iff( equal(var("target"), increment(var("possible_antecedent"))),
             var("possible_antecedent"),
             invoke("decrement", vec![ var("target"), increment(var("possible_antecedent"))]))
           ))
    ],
    invoke("decrement",
      vec![var("~"), literal_u8(0)]
    )
  )

But I will probably learn Hoon instead.

Edit: I thought to add, after reading the sibling comment, that another reason I cut out jets was that basic arithmetic operations were less obviously in scope, because the atoms are byte sequences instead of natural numbers.

For a toy project of mine, I needed a way to encode small programs to send around. I originally wrote a interpreter for the MIPS instruction set, but then I encountered Urbit's functional machine language, "nock", and switched right over to that. It ended up being a much much simpler interpreter with more compact program encodings and a lot fewer arbitrary-feeling decisions involved. Nock also turns out to be a really straightforward compile target for lisp-like languages. Nock is confusing to approach, but it is really very clever. I would recommend learning it if you are in the mood for a puzzle!

Nock: https://github.com/cgyarvin/urbit/blob/master/doc/book/1-noc... My project's nock VM: https://github.com/PeterReid/hoplight/tree/master/vm