From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-19941-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 27012 invoked by alias); 1 Mar 2015 19:47:12 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 19941
Received: (qmail 14519 invoked from network); 1 Mar 2015 19:47:11 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.2
X-Authority-Analysis: v=2.1 cv=X+5rdgje c=1 sm=1 tr=0
 a=v3jdlwE+mftNnR1sUa1KMQ==:117 a=v3jdlwE+mftNnR1sUa1KMQ==:17 a=VNsaWKQvMhEA:10
 a=N659UExz7-8A:10 a=N7tosYGy8q0n2_bQx_cA:9 a=pILNOxqGKmIA:10
Message-id: <54F365AB.4070802@eastlink.ca>
Date: Sun, 01 Mar 2015 11:16:59 -0800
From: Ray Andrews <rayandrews@eastlink.ca>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.4.0
MIME-version: 1.0
To: zsh-users@zsh.org
Subject: Re: grammar triviality with '&&'
References: <54F33934.2070607@eastlink.ca> <13666281425228233@web7o.yandex.ru>
 <54F345D3.9010204@eastlink.ca> <150301104829.ZM16206@torch.brasslantern.com>
In-reply-to: <150301104829.ZM16206@torch.brasslantern.com>
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 7bit

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