I've updated the paper and removed the SELECT, CLOSE and CLOSED procedures as discussed.
I still think a close feature which - in contrast to Go - would just signal all waiting threads and abandon communication could be useful. I implemented this in the C library I use for experiments: https://github.com/rochus-keller/CspChan
> the proposal for it to take a timeout, which could then be detected via execution of ELSE?
It could still be added in future, e.g. as an additional parameter to SEND or RECEIVE, but in a similar way to CLOSE it makes things more complicated, and there is an alternative solution with a separate thread sending after a delay a over a channel which is received in a WITH statement where also the candidate channel waits.
> have you considered asking Dr Wirth for feedback?
I still think a close feature which - in contrast to Go - would just signal all waiting threads and abandon communication could be useful. I implemented this in the C library I use for experiments: https://github.com/rochus-keller/CspChan
> the proposal for it to take a timeout, which could then be detected via execution of ELSE?
It could still be added in future, e.g. as an additional parameter to SEND or RECEIVE, but in a similar way to CLOSE it makes things more complicated, and there is an alternative solution with a separate thread sending after a delay a over a channel which is received in a WITH statement where also the candidate channel waits.
> have you considered asking Dr Wirth for feedback?
I have qualms about bothering him with this in his well-deserved retirement, especially as he has demonstrated with Oberon-07 in which direction he would develop the language (see also https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...).