3 ms·

The CLOSED() function, used after a RECEIVE() strikes as allowing a race. Rather something like: RXORCLOSE(c_j, v_j, VAR closed: BOOLEAN) DO Sj as an addi

The CLOSED() function, used after a RECEIVE() strikes as allowing a race. Rather something like: RXORCLOSE(c_j, v_j, VAR closed: BOOLEAN) DO Sj as an additional guard seems necessary, otherwise these two send side sequences can not be distinguished: SEND(ch, 'a'); SEND(ch, 'a'); CLOSE(ch) SEND(ch, 'a'); CLOSE(ch) Or am I missing something? (and FWIW, discarding the SELECT() in favour of the WITH scheme would strike me as preferable)

Rochus 3y ago
Is this really an issue? So far I didn't care much about close or its synchronization. Isn't just calling CLOSED good enough? Do we really have to be exactly sure when CLOSE was called? If it was an issue I would rather do without CLOSE. EDIT: or maybe just allow CLOSED guards in WITH, similar to SEND or RECEIVE, like WITH SEND(TxChan, text) DO | RECEIVE(FailChan, fail) DO | CLOSED(FailChan) DO END But I think CLOSE makes everything more complicated without a clear use; I mostly added it because Go has it. EDIT2: yet another idea: WITH SEND(TxChan, text) DO | ok := RECEIVE(FailChan, fail) DO END where ok is a BOOLEAN variable and the assignment is optional; looks a bit strange but allows the same closed handling as in Go.
- dfawcus 3y ago
  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...).

Rochus 3y ago

Is this really an issue? So far I didn't care much about close or its synchronization. Isn't just calling CLOSED good enough? Do we really have to be exactly sure when CLOSE was called? If it was an issue I would rather do without CLOSE. EDIT: or maybe just allow CLOSED guards in WITH, similar to SEND or RECEIVE, like WITH SEND(TxChan, text) DO | RECEIVE(FailChan, fail) DO | CLOSED(FailChan) DO END But I think CLOSE makes everything more complicated without a clear use; I mostly added it because Go has it. EDIT2: yet another idea: WITH SEND(TxChan, text) DO | ok := RECEIVE(FailChan, fail) DO END where ok is a BOOLEAN variable and the assignment is optional; looks a bit strange but allows the same closed handling as in Go.

dfawcus 3y ago
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...).