Re: grammar triviality with '&&'

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 4,  9:12am, Ray Andrews wrote:
}
} If an extra degree of freedom and capability was possible, and IF it
} could be implemented with no gotchas, then why not?

Because we don't need the grammar to become any more ad-hoc than it
already has?

Back in the depths of time, one of the reasons zsh was invented was
because csh's grammar was too irregular.  Csh scripts originally (I
can't speak for how tcsh &c. may be now) could in fact be interpreted
one line at a time, and literally were:  "while" loop was processed by
remembering the file position of the string "while" and then when the
"end" was encountered, seeking back and re-reading the lines again.
This made it possible to write some really entertaining scripts that
edited their own code on the fly, but made it impossible to syntax
check a multi-line control structure before beginning to execute it.

The Bourne-shell / POSIX shell grammar is at least regular enough to
be parsed before it is executed, even with all its other warts.
Introducing a case where the command to the left of && / || can be
empty if and only if the conjunction is the first token on a line, is
the kind of irregularity that should be avoided.

Further, in the standard definition of the grammar where pipelines
separated by && or || form a sublist, the terminator that follows is
syntactically significant to the whole sublist.  That is:

	one && two || three &

is parsed as

	{ one && two || three } &

which is not the same as

	one ; [[ $? = 0 ]] && two ; [[ $? = 0 ]] || three &

Now, as it turns out, zsh doesn't actually execute "one" and "two" in
the background when presented with "one && two || three &" but that is
a consequence of other implementation choices and not of the treatment
of "one && two || three" as a syntactic unit.