Conversation

The use case would be for things like building a forth-driven I2C temperature driver, where you might want to regularly send the current temp, and perhaps the "other machine" could change some kind of setting, like a polling rate.
1
If you want to send data you send a "fetch from port" command that reads the next word you send. If you want to read from the port, you send a command that causes the node to write to that port. It's "always be reading & executing words". Not sending data.
1
2
I dread writing external APIs. They are an impossible problem: need to be future proof, but can't know everything ahead of time. So they get really ugly over time. A lot of the Forth lore is about avoiding this altogether: get good at writing simple, special purpose code.
1
2
A message is a program that runs in another context. This is a really good way to look at things. Combine it with embracing statefulness at the receiving end, and compensate that by transactions. Code is easy to generate, data is hard to parse. Prefer printing over parsing.
1
2
Show replies