Re: grammar triviality with '&&'

[ZyX <kp-pav@xxxxxxxxx>]

01.03.2015, 22:48, "Ray Andrews" <rayandrews@xxxxxxxxxxx>:
> On 03/01/2015 10:48 AM, Bart Schaefer wrote:
>>  On Mar 1,  9:01am, Ray Andrews wrote:
>>  }
>>  } I see, so it's not a 'hard' syntactic issue
>>
>>  Actually it IS a "hard" syntactic issue, in the sense that the grammar
>>  for all *nix shells [1] both immemorial and standard, formally defines
>>  newline as equivalent to semicolon.
>
> I see.  If newline == semicolon, then the acceptable variations in line
> wrap that I've
> noticed have simply been within that rule and there is no look ahead as
> I presumed.
> This is a good thing to know.  As usual I refer in my head back to C
> where line wrap
> issues virtually never exist, but that's obviously far more complicated
> to parse.

C is far easier to parse. Two main complications are preprocessor and state: you cannot parse some constructs without knowing about typedefs and you can parse nothing without #defines. But C grammar is not as complicated as zsh one.

Handling newlines here is not a complication, not a tiny bit of this: after preprocessor you can simply translate newline to space (except when inside quotes). For preprocessor newline without `\` always ends the statement, `\\\n` is ignored.

Though it would not be so easy if you wanted to make C interpreted. Dunno how existing C interpreters handle this: never tried them, but it would be logical to run something when interpreter received newline and has a complete top-level statement.

> What that rule looses in formatting flexibility it gains in brevity and
> easier parsing
> so it becomes clear why an interpreted language makes that choice.