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.

This is one of the reasons I included all arithmetic operations in ax:

https://github.com/mnemnion/ax/blob/master/ax%20spec.md

Also because once you say 'natural number', the arithmetic operations are already in scope, so to speak.

I get that Nock is half philosophical perfection, so it makes sense to me. All those operations can be trivially defined without any cost, but they muck up the spec (Does your language gzip to 340 bytes? Can I wear it on a t-shirt?).

Not that there's anything wrong with defining a language that is usable out of the box, but at the same time muh intellectual purity.

You might have to use the back of a t-shirt.

A spec which includes the term 'natural numbers' but not subtraction might even be argued to be incomplete, rather than minimal. Ymmv.

You can synthesize subtraction from recursion and addition. Peano numbers really only have successor, but is still a valid encoding.

Really, you aren't wrong. But then how would we be able to advertise how stupid Nock is for those sweet internet points? It can't even do subtraction! Come see, tickets one dollar!

Addition is kinda the prime operation that is needed - everything else can be dissolved into it, but without it the jet system doesn't hold up because your language can't really /do/ anything. If you didn't require jets to be transparent to the reduction, you could just have /all/ operations be jets and not even pretend Nock was useful without them.

Check out https://github.com/tibru/tibru No primitive arithmetic operations at all, no need for jets but the same time complexity as arithmetic in C just with a higher constant factor.