From: Ray Andrews <rayandrews@eastlink.ca>
To: zsh-users@zsh.org
Subject: Re: grammar triviality with '&&'
Date: Fri, 06 Mar 2015 13:01:46 -0800 [thread overview]
Message-ID: <54FA15BA.3070207@eastlink.ca> (raw)
In-Reply-To: <150306094359.ZM9698@torch.brasslantern.com>
On 03/06/2015 09:43 AM, Bart Schaefer wrote:
> } I don't think that the grammar would become more complex.
>
> What you're both missing or at least glossing over is the interaction
> between the grammar and the interactive interpreter.
>
> There goals are: (1) the grammar for scripts is identical to the grammer
> for interactive use, (2) the execution order is identical both in scripts
> and in interactive use, and (3) when used interactively, the input can be
> interpreted [commands executed] as soon as a complete syntactic structure
> has been recognized.
Sounds sane.
> Under the current grammar, the interpreter always "knows," at the point
> where a line break occurs, whether or not it has a complete syntactic
> element that it can execute. If you allow the and_or producion to put
> a linebreak before AND_IF / OR_IF, then until it encounters an explicit
> ";" or "&" (or some other lookahead token that can't appar at that
> position in the pipeline production) the interpreter doesn't "know"
> whether it has actually reached the end of the "and_or" production.
>
> Therefore it would either violate (2) to speculatively execute what has
> been seen so far, or it would violate (3) to wait for the next token to
> complete the lookahead. Sure, we could either discard goal (1) to
> make this an interactively-only feature [there's at least precedent for
> that with setopts], or we can discard goal (2); we can do whatever
> we want. I assume you'd find it way too annoying to discard (3).
Don't blame me! I'm just riding along with Vincent's logic, he can
argue this with
real knowledge, I'm just seeing what's at the bottom of this.
When I type at the prompt, it clearly knows when I'm not
finished, but If I type ' [ -e file1 ] ENTER', it goes to the next
prompt, because it has no
way of knowing that I intended to add an '&&' after it on the next
line. Quite so.
But surely that's not the issue. The issue is whether
| two
can know to implicity grab the already existing return value from the
last command,
whatever it may have been. Yup, the previous line is executed and
finished and gone,
but it has set the errorlevel, and that does persist, so it is
legitimately there. Why
can't it be used? I see it as violating none of your three rules. It
would be the same
interactively or in scripts, and it would execute at syntactic
completion. All that would
change is that an obviously incomplete AND_IF would default to grabbing
the previous
return value (which is still there). Anyway, the parser would be making a
concession, and why should it? No really good reason. I'm satisfied,
unless similar
concessions are made routinely elsewhere. Nope, it ain't broken, don't
fix it.
> But this is in a sense analogous to suggesting that
>
> one | two | three
>
> could wait to see what happens to "one" before deciding whether to send
> the output along to "two".
>
> one
> | two
> | three
Yes. Exactly. The question was why that's not permitted, but I think I
see why.
>
> just so that you can decide later whether you're interested in adding
> yet another stage to the pipeline. Or at least I hope you would not
> suggest that, though if you look through the list archives people have
> in fact asked how to capture output so they can re-use it later. See
> Functions/Misc/keeper for an example.
Nope. I don't want to break things more broken than they already are.
> In any case, I'm done trying to explain this. We've already put the lie
> to the word "triviality" in the subject of this thread.
>
Amen! It was quite innocent at the time ;-) But it has been deeply
informative.
next prev parent reply other threads:[~2015-03-06 21:31 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-01 16:07 Ray Andrews
2015-03-01 16:43 ` ZyX
2015-03-01 17:01 ` Ray Andrews
2015-03-01 18:48 ` Bart Schaefer
2015-03-01 19:00 ` ZyX
2015-03-01 19:16 ` Ray Andrews
2015-03-01 20:48 ` ZyX
2015-03-01 18:49 ` Lawrence Velázquez
2015-03-02 2:27 ` Vincent Lefevre
2015-03-02 3:12 ` Ray Andrews
2015-03-02 5:22 ` Lawrence Velázquez
2015-03-02 3:53 ` Kurtis Rader
2015-03-02 4:18 ` Ray Andrews
2015-03-02 5:22 ` Kurtis Rader
2015-03-02 16:17 ` Ray Andrews
2015-03-02 18:52 ` Kurtis Rader
2015-03-02 19:03 ` ZyX
2015-03-02 20:16 ` Kurtis Rader
2015-03-03 4:15 ` ZyX
2015-03-03 4:43 ` Kurtis Rader
2015-03-04 15:03 ` Vincent Lefevre
2015-03-04 19:07 ` ZyX
2015-03-02 19:25 ` Ray Andrews
2015-03-02 10:46 ` Vincent Lefevre
2015-03-02 11:06 ` Peter Stephenson
2015-03-02 19:19 ` Bart Schaefer
2015-03-04 14:47 ` Vincent Lefevre
2015-03-05 1:51 ` Bart Schaefer
2015-03-05 10:06 ` Peter Stephenson
2015-03-02 8:54 ` Bart Schaefer
2015-03-02 10:31 ` Vincent Lefevre
2015-03-02 16:31 ` Ray Andrews
2015-03-02 16:49 ` Bart Schaefer
2015-03-02 17:38 ` Ray Andrews
2015-03-02 18:51 ` Bart Schaefer
2015-03-04 8:55 ` Vincent Lefevre
2015-03-04 17:12 ` Ray Andrews
2015-03-06 4:59 ` Bart Schaefer
2015-03-06 16:10 ` Ray Andrews
2015-03-06 20:23 ` Lawrence Velázquez
2015-03-06 21:25 ` Ray Andrews
2015-03-06 16:32 ` Vincent Lefevre
2015-03-06 17:43 ` Bart Schaefer
2015-03-06 21:01 ` Ray Andrews [this message]
2015-03-09 11:26 ` Vincent Lefevre
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=54FA15BA.3070207@eastlink.ca \
--to=rayandrews@eastlink.ca \
--cc=zsh-users@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).