3 ms·

Thanks for the feedback. What do you think about the SELECT function? Should I drop it in favour of the extended WITH statement?

by Rochus 3y ago

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.

Thanks for the feedback. What do you think about the SELECT function? Should I drop it in favour of the extended WITH statement?

by 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.