From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1901 invoked by alias); 1 Mar 2015 20:54:23 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 19942 Received: (qmail 19833 invoked from network); 1 Mar 2015 20:54:19 -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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_FSL_HELO_BARE_IP_2 autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1425242895; bh=UU8qsTwjABlw86KMCi2qUD/kKC3ufy+AGXkn4O/OzDk=; h=From:To:In-Reply-To:References:Subject:Date; b=n0UstBOBhb9eomOI3tpkiEqj3oRF7/hIGQi1TqUyEXpzGOd0ynfSQhSlxF+ZUY1Xx 0JMJAzkEgdwCqhQ780EY0aQP2/FhGo/2v9CUWGsVTTxX9Qhd8reUY0Ha9nYOCtPDcT mK5z2TWZl1jSZZoIqjyEDnfmStg9VwmO1WAlOiSc= From: ZyX To: Ray Andrews , "zsh-users@zsh.org" In-Reply-To: <54F365AB.4070802@eastlink.ca> References: <54F33934.2070607@eastlink.ca> <13666281425228233@web7o.yandex.ru> <54F345D3.9010204@eastlink.ca> <150301104829.ZM16206@torch.brasslantern.com> <54F365AB.4070802@eastlink.ca> Subject: Re: grammar triviality with '&&' MIME-Version: 1.0 Message-Id: <440741425242894@web21h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 01 Mar 2015 23:48:14 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r 01.03.2015, 22:48, "Ray Andrews" : > 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.