syntax support for braced / command-list coproc

[abathur]

The parser falls over on bash's braced coproc form:

$ osh -c 'coproc TEST { echo foo; }; cat </dev/fd/${TEST[0]}'
  coproc TEST { echo foo; }; cat </dev/fd/${TEST[0]}
                          ^
[ -c flag ]:1: Unexpected right brace

$ bash -c 'coproc TEST { echo foo; }; cat </dev/fd/${TEST[0]}'
foo

I brought this up previously on zulip (https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/coproc.20syntax.3F) so I'm not really expecting a change of policy here. Opening an issue to document and cross-link, since I finally had a resholve user other than myself encounter/report this :) abathur/resholve#79

Here's the reporter's example: https://github.com/tejing1/nixos-config/blob/45d10ed6c530f80abf19e7c8e1cb028de3ebdb92/homeConfigurations/tejing/email/mailwatch.sh#L15

Seeing their report also reminded me that I had my own case where I wanted to use the named form (but avoided it): https://github.com/abathur/lilgit/blame/main/lilgit.bash#L3-L7

[andychu]

Ah OK so are these issues where syntax alone would help?

Parsing it is probably significantly easier than running it. Even though that turns a parse error into a runtime error, it could be OK (could hide it between parse_strict or something). I still feel like it is a poorly designed feature but parse support could be reasonable

This is some more evidence that people use it, which is helpful

[abathur]

At least in resholve's case, syntax support alone would help.

I admit I'm a little unsure about this. I wouldn't want it to be a subtle trap for OSH users (especially if it globally softened always-bad brace syntax to a runtime error?)

Since OSH doesn't support coproc at all for now, I guess there might be a positive UX outcome for being able to tolerate the syntax in the context of a coproc: OSH could raise a coherent error that points users to documentation on the state of coproc, regardless of which bash form they're using?