Re: Parse error (lack thereof) on incomplete loops

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, Oct 5, 2018 at 2:14 AM Peter Stephenson
<p.stephenson@xxxxxxxxxxx> wrote:
>
> The original expression is parsed as
>
> {
>   while {
>     false
>     while false; do
>     done
>     }; do
>   done
> }
>
> which is an infinite loop because of the point above.  [...]  However,
> apart from that there's nothing new [...]  The only new feature is that all
> the "do ... done" clause has become optional if it's possible to infer
> there's nothing there.  That seems to me entirely consistent.

I would contend that the point of SHORT_LOOPS is not to be able to
omit the loop body, it's to be able to abbreviate the syntax that
delimits the loop conditions and separates them from the loop body.
But of what possible use, for example, is { repeat 5 } which this
"accidental feature" allows?  Or { select foo } or { for x } ?  And if
{ for x } is allowed, why is { for x in z } an error, particularly if
you're arguing that it's obvious the "do-done" is meant to be empty?
Why should it have to be { for x in z; } when a trailing semicolon is
not required in other brace expressions?

> Without a "do" while doesn't know where the expression ends.  That's
> fundamental to how SHORT_LOOPS works

No it isn't.  The documentation explicitly says:

  For the if, while and until commands, in both these cases the test part
  of the loop must also be suitably delimited, such as by `[[ ... ]]' or
  `(( ... )), else the end of the test will not be recognized.

"Both these cases" refers to:
#1 - sublist is of the form `{ list }'
#2 - the SHORT_LOOPS option is set

So you don't get to claim that SHORT_LOOPS is intended to except you
from that restriction.  The "]]" or "))" tell while where the
expression ends.

In none of the examples given in this thread so far has the test
expression been delimited that way.