From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13048 invoked by alias); 6 Mar 2015 09:41:17 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34664 Received: (qmail 1376 invoked from network); 6 Mar 2015 09:41:04 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f126d000001e9a-18-54f9759bf78c Date: Fri, 06 Mar 2015 09:40:39 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Aliasing separators (Re: grammar triviality with '&&') Message-id: <20150306094039.3d968c63@pwslap01u.europe.root.pri> In-reply-to: <150305174240.ZM8732@torch.brasslantern.com> References: <54F33934.2070607@eastlink.ca> <13666281425228233@web7o.yandex.ru> <54F345D3.9010204@eastlink.ca> <20150302022754.GA7449@xvii.vinc17.org> <20150302104619.GC6869@xvii.vinc17.org> <20150302110610.2e2c7e86@pwslap01u.europe.root.pri> <20150304144756.GA27231@ypig.lip.ens-lyon.fr> <150304175112.ZM19818@torch.brasslantern.com> <20150305100638.55631238@pwslap01u.europe.root.pri> <150305090720.ZM8441@torch.brasslantern.com> <20150305174011.0be5a31e@pwslap01u.europe.root.pri> <150305174240.ZM8732@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsVy+t/xy7qzS3+GGKztErQ42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGZ8nH2cpeC1RsWLLIfYGxkvCXYycHBICJhLrJ71jg7DFJC7c Ww9kc3EICSxllFh74yYLhLOESeL41jWsEM42RonHX/6zgrSwCKhK/Lh1DKydTcBQYuqm2Ywg toiAuMTZtedZQGxhAWeJY3NOM4PYvAL2EttuvAOyOTg4BSwlmrYbQMx8wirRsvgv2Ex+AX2J q38/MUGcZC8x88oZRoheQYkfk++BzWQW0JLYvK2JFcKWl9i85i3YfCEBdYkbd3ezT2AUmoWk ZRaSlllIWhYwMq9iFE0tTS4oTkrPNdQrTswtLs1L10vOz93ECAnbLzsYFx+zOsQowMGoxMPb kfozRIg1say4MvcQowQHs5II77cCoBBvSmJlVWpRfnxRaU5q8SFGJg5OqQbGaQ/5+5lmCVu1 fN7M9ZbXJbl56YezmX823u7yjU+PODdj2oa1X312zj+2vqrrSrhnuzRDskrh/69Jv64oPDKU l1n6fULVtwt5LqacTnY7ZjjOYV519vwqU+EVx7h9A6xnCTDsuLXZ98G3tnWS2sdXSpzPm7o/ t6msd4FR0U/Zr/8P/qgKFgwvUmIpzkg01GIuKk4EAE3/g605AgAA OK, to state my basic position (though it's kind of moot --- as I said I don't think anybody really needs the change) 1. tokenisation is part of lexing 2. alias expansion comes between lexing and parsing 3. any result of lexing is game for alias expansion, unless you make stricter rules than zsh already has. But this discussion isn't really going anywhere. On Thu, 5 Mar 2015 17:42:40 -0800 Bart Schaefer wrote: > torch% &&bar > > I would argue that the "&&" is NOT "in command position" because in the > normal lexical situation "command position" ENDS just to the left of any > separator. There's NOTHING in "command position" in that example. > > Either "&&" is a separator token and should act like one, or it isn't > and in that example the alias for "&&bar" should be looked up instead. Well, that's not how the lexer actually works. It's been told it's in command position and it fetches the next token. So whatever comes at the start of the line *must* be in command position. The parser can throw an error if it thinks it shouldn't be, but that's after alias expansion (so much is uncontroversial). Actually, come to think of it, I think you mean the opposite: normally, when you encounter a "&&", you're expecting the continuation of the current command; here, it's the reverse --- you're expecting the start of a command, and encounter something which only occurs after a command. So you might argue that you "turn off" "&&" analysis in the same way that you "turn on" "(" analysis at the same point --- and that example's relevant because when "(" is at the start of a line we only take one character at a time, i.e. print ((foo)) ((print foo); print bar) are treated entirely differently. (By the way, aliasing "(" here therefore does exactly what you'd expect: in the second case it gets replaced as a single token eacht time it occurs, in the first place not. I don't know of a good use for this, which is a kind of motto for the current discussion.) But I don't really buy that; we know a ";" separator has to be detected at this point whether there's a command there or not. So there's not really any sensible reason for not turning "&&" into a token. Given that, in any case, no one is actually suggesting we change the lexer to do something different with "&&" I don't think I see the relevance anyway. "&&" is a token and either expanded as an alias or not, just as you get a parse error with ";;" because it's always treated as a token whether we're in a case or not. > } > Aliasing only of STRING tokens is exactly the right thing and this > } > change is simply wrong. The doc only says "before parsing" as a > } > shorthand instead of a long explaination about how the alias is > } > replaced and then parsed all over again. > } > } If you can produce an alternative patch describing the previous position > } properly, go ahead. I don't think anyone is actually screaming to use > } this change. > > I'll think about a documation patch if that's what you mean. Yes, we certainly wouldn't need any code change in the other case. pws