Sleep-oriented programming -- async

[TeamDman]

NAME "demo 3.1 - sleep-oriented programming 😴"
LOOP
      INPUT redstone:: FROM source -- where 'source' is a minecraft:redstone_block
      OUTPUT redstone:: TO buffer -- where 'buffer' is a sfm:redstone_buffer
    SLEEP 10 SECONDS
    FORGET
      INPUT redstone:: FROM buffer
      OUTPUT redstone:: TO source
    SLEEP 10 SECONDS 
END

NAME "demo 3.2 - transpiled sleepy program"
EVERY 20 TICKS DO
  INPUT redstone:: FROM source
  OUTPUT redstone:: TO buffer
END
EVERY 20n+10 TICKS DO
  INPUT redstone:: FROM buffer
  OUTPUT redstone:: TO source
END

• Sleep statements can be transpiled to global-offset timer triggers
• Partial/no forgets would be untranspilable because INPUT statements contain state for the duration of a program tick

NAME "demo 3.3 - sleepy failure"
LOOP
  INPUT 10 FROM a -- where 'a' starts with 5
  OUTPUT TO b -- 'a' now has 0
SLEEP 10 TICKS -- 'a' now has 10 (outside influence)
  OUTPUT TO b -- only 5 should be moved
END

• This cannot be converted to a global offset timer trigger pair because the program has state crossing the sleep boundary

Therefore, programs must have a persistable state for sleep to make sense

Work-stealing async-runtimes are a well-investigated topic we could learn from.

See: java project loom, rust-tokio

https://www.youtube.com/watch?v=zPhkg8dYysY

A sleep statement would basically be awaiting a delayed promise/future.

Await could be useful in other contexts

EVERY 20 TICKS DO
  INPUT FROM ingredients
  OUTPUT 10 iron_ore TO furnace TOP SIDE
AWAIT smelt_iron_ore_recipe.duration + 1 ticks
FORGET
  INPUT FROM furnace BOTTOM SIDE
  OUTPUT TO results
END

Enforcing zero-state-between-sleep-boundaries and simply rewriting as timer triggers with offset seems the best approach since it lets users write programs in the intuitive manner but doesn't require introducing new fundamentals to the mod