3 ms·

Thanks. I'm neither happy yet with the SELECT() function. Concerning your proposal, I would rather not introduce a completely new control structure. But one co

by Rochus 3y ago

Thanks. I'm neither happy yet with the SELECT() function. Concerning your proposal, I would rather not introduce a completely new control structure. But one could - like Wirth with the type CASE statement in Oberon-07 - reuse the WITH statement like: WITH SEND(TxChan, text) DO | RECEIVE(FailChan, fail) DO END where I would just have to change the Guard a bit like Guard = qualident ':' qualident | SEND ActualParameters | RECEIVE ActualParameters and even ELSE is available. What do you think?

dfawcus 3y ago
I had a read of the page after you updated it. I find the proposed SELECT function to be unwieldy, to the extent that one would really want some syntax added instead. Assuming I'm correctly inferring from the above, the WITH looks better. Presumably one could have multiple SEND and/or RECEIVE function clauses in the WITH statement, so acting as an equivalent to the Go Select? What would ELSE do? It it acting the same as the default clause in a Go select, i.e. allowing for a non-blocking call? The one other question with the above is how would one detect a closed channel when the RECEIVE clause hits?
- Rochus 3y ago
  > Presumably one could have multiple SEND and/or RECEIVE function clauses in the WITH statement, so acting as an equivalent to the Go Select? Correct. Here is the specification: https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#with-statements https://github.com/oberon-lang/specification/blob/master/The.... You can have an unlimited number of guards. > What would ELSE do? It it acting the same as the default clause in a Go select, i.e. allowing for a non-blocking call? Correct, that's the idea. > how would one detect a closed channel when the RECEIVE clause hits? EDIT: I added yet another build-in procedure which returns the closed state of a channel. A blocking WITH would continue if no channel was ready to communicate, but at least one was closed.
  - 082349872349872 3y ago
    I like repurposing WITH, as it already had the semantics of selecting a single branch out of an unordered collection of guarded branches (or the ELSE as complement).
    - Rochus 3y ago
      Thanks for the feedback. What do you think about the SELECT function? Should I drop it in favour of the extended WITH statement?
      - 082349872349872 3y ago
        I would drop the SELECT as proposed, in favour of extended WITH. A potentially useful SELECT function (if runtime-variable communication graphs are of interest, which they may not be?) would be one which took an array of channels and directions (à la poll), or similar data structure, as a parameter. Edit: I also suspect that the semantics of channel closure are unlikely to be as simple as you are hoping. (but maybe do something like tcp sockets, and force a consumer to drain the channel before orderly closure?) (between array riders and lack of display access to variables in enclosing scopes, OBERON SA seems to have evolved in a direction converging upon C?)
        Rochus 3y ago
        > A potentially useful SELECT function would be one which took an array of channels and directions That would actually be even a better idea than my present SELECT function, but I don't have a good solution yet for the (receive) variables. The best I can think of is just an array for the values, but that needs a lot of extra copies. I would rather prefer a built-in function than a separate module as in Go. > OBERON SA seems to have evolved in a direction converging upon C Not sure what you mean. EDIT: concerning close synchronization see https://news.ycombinator.com/item?id=38777973 https://news.ycombinator.com/item?id=38777973
        dfawcus 3y ago
        For a similar case in Go, where I wanted a run time variable shape of graph, I was able to do without using an array. That was simply by spawning more goroutines. So for the rx (mux) side, they all just write in to one shared chan which it then further processed. For the tx (demux) side, it is a bit simpler, but again with just an extra goroutine per tx side. This was in a scenario where multiple clients were performing run-time registration with a mux/demux API based upon the comms needs of those specific clients. There is the Go reflect.Select, however it is awkward, and seems to be discouraged, hence I simply used the pattern above.

by Rochus 3y ago

dfawcus 3y ago

I had a read of the page after you updated it. I find the proposed SELECT function to be unwieldy, to the extent that one would really want some syntax added instead. Assuming I'm correctly inferring from the above, the WITH looks better. Presumably one could have multiple SEND and/or RECEIVE function clauses in the WITH statement, so acting as an equivalent to the Go Select? What would ELSE do? It it acting the same as the default clause in a Go select, i.e. allowing for a non-blocking call? The one other question with the above is how would one detect a closed channel when the RECEIVE clause hits?

Rochus 3y ago
> Presumably one could have multiple SEND and/or RECEIVE function clauses in the WITH statement, so acting as an equivalent to the Go Select? Correct. Here is the specification: https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#with-statements https://github.com/oberon-lang/specification/blob/master/The.... You can have an unlimited number of guards. > What would ELSE do? It it acting the same as the default clause in a Go select, i.e. allowing for a non-blocking call? Correct, that's the idea. > how would one detect a closed channel when the RECEIVE clause hits? EDIT: I added yet another build-in procedure which returns the closed state of a channel. A blocking WITH would continue if no channel was ready to communicate, but at least one was closed.
- 082349872349872 3y ago
  I like repurposing WITH, as it already had the semantics of selecting a single branch out of an unordered collection of guarded branches (or the ELSE as complement).
  - Rochus 3y ago
    Thanks for the feedback. What do you think about the SELECT function? Should I drop it in favour of the extended WITH statement?
    - 082349872349872 3y ago
      I would drop the SELECT as proposed, in favour of extended WITH. A potentially useful SELECT function (if runtime-variable communication graphs are of interest, which they may not be?) would be one which took an array of channels and directions (à la poll), or similar data structure, as a parameter. Edit: I also suspect that the semantics of channel closure are unlikely to be as simple as you are hoping. (but maybe do something like tcp sockets, and force a consumer to drain the channel before orderly closure?) (between array riders and lack of display access to variables in enclosing scopes, OBERON SA seems to have evolved in a direction converging upon C?)
      - Rochus 3y ago
        > A potentially useful SELECT function would be one which took an array of channels and directions That would actually be even a better idea than my present SELECT function, but I don't have a good solution yet for the (receive) variables. The best I can think of is just an array for the values, but that needs a lot of extra copies. I would rather prefer a built-in function than a separate module as in Go. > OBERON SA seems to have evolved in a direction converging upon C Not sure what you mean. EDIT: concerning close synchronization see https://news.ycombinator.com/item?id=38777973 https://news.ycombinator.com/item?id=38777973
      - dfawcus 3y ago
        For a similar case in Go, where I wanted a run time variable shape of graph, I was able to do without using an array. That was simply by spawning more goroutines. So for the rx (mux) side, they all just write in to one shared chan which it then further processed. For the tx (demux) side, it is a bit simpler, but again with just an extra goroutine per tx side. This was in a scenario where multiple clients were performing run-time registration with a mux/demux API based upon the comms needs of those specific clients. There is the Go reflect.Select, however it is awkward, and seems to be discouraged, hence I simply used the pattern above.