zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Aliasing separators (Re: grammar triviality with '&&')
Date: Fri, 06 Mar 2015 09:40:39 +0000	[thread overview]
Message-ID: <20150306094039.3d968c63@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <150305174240.ZM8732@torch.brasslantern.com>

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 <schaefer@brasslantern.com> 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


  parent reply	other threads:[~2015-03-06  9:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <54F33934.2070607@eastlink.ca>
     [not found] ` <13666281425228233@web7o.yandex.ru>
     [not found]   ` <54F345D3.9010204@eastlink.ca>
     [not found]     ` <D0509295-7DA9-4F18-9E3D-D50C0A756998@larryv.me>
     [not found]       ` <20150302022754.GA7449@xvii.vinc17.org>
     [not found]         ` <CABx2=D8efL3X2tfB+_+VweY2yye6EhaMNbJa3b3jJeVMp=7gaQ@mail.gmail.com>
     [not found]           ` <20150302104619.GC6869@xvii.vinc17.org>
     [not found]             ` <20150302110610.2e2c7e86@pwslap01u.europe.root.pri>
     [not found]               ` <CAH+w=7YoHjN85hqOZVywOfYGZqvU74vZrbE84Ln+V2HQi-6nSA@mail.gmail.com>
     [not found]                 ` <20150304144756.GA27231@ypig.lip.ens-lyon.fr>
2015-03-04 15:18                   ` grammar triviality with '&&' Peter Stephenson
2015-03-04 21:13                     ` Daniel Shahaf
2015-03-04 22:05                     ` Mikael Magnusson
2015-03-05  9:46                       ` Peter Stephenson
     [not found]                   ` <150304175112.ZM19818@torch.brasslantern.com>
     [not found]                     ` <20150305100638.55631238@pwslap01u.europe.root.pri>
2015-03-05 17:07                       ` Aliasing separators (Re: grammar triviality with '&&') Bart Schaefer
2015-03-05 17:40                         ` Peter Stephenson
2015-03-06  1:42                           ` Bart Schaefer
2015-03-06  4:13                             ` Mikael Magnusson
2015-03-06 16:43                               ` Vincent Lefevre
2015-03-06  9:40                             ` Peter Stephenson [this message]
2015-03-06 19:26                               ` Bart Schaefer
2015-03-07 15:52                                 ` Peter Stephenson
2015-03-07 17:18                                   ` Ray Andrews
2015-03-07 21:10                                   ` Bart Schaefer
2015-03-09 11:46                                     ` Vincent Lefevre
2015-03-09 16:33                                       ` Peter Stephenson
2015-03-09 17:03                                         ` Bart Schaefer
2015-03-09 17:39                                           ` Peter Stephenson
2015-03-09 17:47                                           ` Ray Andrews

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150306094039.3d968c63@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).