Implement true priority semantics for PRI ALT / PRI PAR

[associate-1]

Context

PR #76 added parsing and transpilation support for PRI ALT and PRI PAR. However, the current implementation treats them identically to their non-priority counterparts — PRI ALT maps to Go's select (which chooses uniformly at random among ready cases) and PRI PAR maps to goroutines + sync.WaitGroup (which have no scheduling priority).

This means programs that depend on priority ordering for correctness will not behave the same as on a real occam/transputer runtime.

What true priority semantics would require

PRI ALT

In occam, PRI ALT tries guards in order — the first ready guard wins. Go's select does not support this. Possible approaches:

• Cascaded non-blocking receives: Try each channel in order using reflect.Value.TryRecv() or select with default, falling back to a blocking select only if none are ready
• Polling loop with backoff: Repeatedly check channels in priority order until one is ready
• Both approaches have tradeoffs around latency, CPU usage, and fairness

PRI PAR

In occam, PRI PAR gives the first process higher scheduling priority. Go's runtime does not expose goroutine priority. Possible approaches:

• runtime.LockOSThread() + OS thread priority: Platform-specific, limited portability
• Cooperative yielding: Not truly enforceable in Go
• May be acceptable to document as unsupported (PRI PAR is rarely relied upon for correctness in practice)

Current state

• PRI ALT and PRI PAR are parsed and the AST stores a Priority bool flag
• Codegen does not consult the flag — both produce the same output as ALT/PAR
• This is sufficient for programs that use PRI as a hint but don't depend on priority for correctness