“This is our whole routine, that does something or other for people.”
routine {
  “This bit will grab some text from the disk; it will block, and take a while to do so.”
  a ← routine { get.some.text.from.the.disk(some.location.to.get.text.from) }

  “This one will do the same thing, but get it from the network instead, and take a different amount of time.”
  b ← routine { get.some.text.from.a.network.resource(obviously.google.duh) }

  “Finally, this simplistic piece adds two bits of text together and prints the result.”
  c ← routine { print.to.the.terminal(join.two.strings(@1, @2)) }

  “This is the crux: the ‘sync abstraction’ here, is what allows us to very clearly declare what, where, depends
   on what else, without having to use any unfamiliar or complex syntax, or anything, really, other than our
   basic, familiar, elements: `routine`s, `list`s, and lookups on them:”
  c( a(), b() )

  “The rest of this routine doesn’t depend upon the results of `c()`, and thus will execute in parallel with
   `c()`, whatever it has to do.”
  do.some.stuff.that.doesn’t.depend.on.c.at.all!()
}