How BlueSpec's Guarded Atomic Actions could be translated to SUS

It's becoming a convention for SUS code to use try_ and may_ prefixes for "guarding" actions and triggers. For instance, look at the FIFO interface: output bool may_push and action push: T data_in. Likewise the other side of the FIFO might see input bool try_pop and trigger pop : T data_out

We could have language constructs for try_ and may_ variants of actions & triggers

Implicitly, when seeing something like

when x == 4 {
  action receive_data : int a, bool b {}
}

The compiler could insert a new output port output bool may_receive_data = x == 4.

Sadly, this doesn't translate too well to triggers. A naked trigger my_trigger takes no condition. Unless we add some kind of guard {} block?

Something like

FIFO fifo
guard { // Implicitly converts to "when fifo.may_pop & try_data_valid"
  float data = fifo.pop()
  
  trigger data_valid : data // Implicitly spawns an action try_data_valid
}

Start by reviewing the FIFO interface examples and the proposed try_, may_, and guard {} syntax in the issue. Determine how guarded actions and triggers should translate to SUS, including trigger conditions and implicit ports. Done means the language behavior and translation rules are specified clearly enough to implement and test.