3 ms·

Actually, I was going to suggest that if CLOSE don't fit here, maybe just omit it from your channel version. I first came across it in the Go version of them.

Actually, I was going to suggest that if CLOSE don't fit here, maybe just omit it from your channel version. I first came across it in the Go version of them. The libtask/libthread and Alef versions do not include it. Its absence is not really an issue, as the same information can simply be explicitly included in how one uses the channel and the data it carries. For Go, it works well only because of the multiple return values being present in the select statement.

082349872349872 3y ago
Between this response and https://news.ycombinator.com/item?id=38780435 https://news.ycombinator.com/item?id=38780435 it sounds like the original WITH is rather close (modulo the proposal for it to take a timeout, which could then be detected via execution of ELSE?) Rochus, have you considered asking Dr Wirth for feedback? I haven't corresponded with him in about a decade but he was very willing to chat about tradeoffs in language features at the time.
- Rochus 3y ago
  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 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+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...).

082349872349872 3y ago

Between this response and https://news.ycombinator.com/item?id=38780435 https://news.ycombinator.com/item?id=38780435 it sounds like the original WITH is rather close (modulo the proposal for it to take a timeout, which could then be detected via execution of ELSE?) Rochus, have you considered asking Dr Wirth for feedback? I haven't corresponded with him in about a decade but he was very willing to chat about tradeoffs in language features at the time.

Rochus 3y ago
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 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+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...).