zsh-workers
 help / Atom feed
* [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted
@ 2018-12-15 20:26 Joey Pabalinas
       [not found] ` <1544925190.621790.1610325216.065C6F48@webmail.messagingengine.com>
  0 siblings, 1 reply; 7+ messages in thread
From: Joey Pabalinas @ 2018-12-15 20:26 UTC (permalink / raw)
  To: Zsh Workers Mailing List; +Cc: Joey Pabalinas

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

In code such as:

> hobbes% () { for arg do print -r $arg; done; } 1 2 3
> 1
> 2
> 3

the implicit `in "$@"` added when the `in word ...` list is omitted
also implicitly appends the separator term, making the above
code valid.

This is fairly innocuous behavior and is POSIX-compliant, so document
this odd edge case rather than risk regressions attempting to change
the lexer/parser code.
---
 Doc/Zsh/grammar.yo | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Doc/Zsh/grammar.yo b/Doc/Zsh/grammar.yo
index d2c7cd29c289287066..33aa3a4c5965771971 100644
--- a/Doc/Zsh/grammar.yo
+++ b/Doc/Zsh/grammar.yo
@@ -185,11 +185,12 @@ cindex(loops, for)
 item(tt(for) var(name) ... [ tt(in) var(word) ... ] var(term) tt(do) var(list) tt(done))(
 where var(term) is at least one newline or tt(;).
 Expand the list of var(word)s, and set the parameter
 var(name) to each of them in turn, executing
 var(list) each time.  If the tt(in) var(word) is omitted,
-use the positional parameters instead of the var(word)s.
+use the positional parameters with a var(term) implicitly
+appended instead of the var(word)s.
 
 More than one parameter var(name) can appear before the list of
 var(word)s.  If var(N) var(name)s are given, then on each execution of the
 loop the next var(N) var(word)s are assigned to the corresponding
 parameters.  If there are more var(name)s than remaining var(word)s, the
-- 
Cheers,
Joey Pabalinas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted
       [not found] ` <1544925190.621790.1610325216.065C6F48@webmail.messagingengine.com>
@ 2018-12-16  2:01   ` Joey Pabalinas
  2018-12-16 11:54     ` Daniel Shahaf
  0 siblings, 1 reply; 7+ messages in thread
From: Joey Pabalinas @ 2018-12-16  2:01 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Workers Mailing List, Joey Pabalinas

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Sun, Dec 16, 2018 at 01:53:10AM +0000, Daniel Shahaf wrote:
> Joey Pabalinas wrote on Sat, 15 Dec 2018 10:26 -1000:
> > This is fairly innocuous behavior and is POSIX-compliant, so document
> > this odd edge case rather than risk regressions attempting to change
> > the lexer/parser code.
> 
> If preventing regressions is your goal, why not add a regression test using this syntax?

Sorry, maybe my commit message was a bit unclear. I meant instead of
trying to poke at the parser/lexer code to make the behavior match the
documentation, I figured it's easier to just do it the other way and
document the weird edge case.

Sorry for the ambiguity (and the double send, forgot to CC the list),
should I revise the commit description?

-- 
Cheers,
Joey Pabalinas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted
  2018-12-16  2:01   ` Joey Pabalinas
@ 2018-12-16 11:54     ` Daniel Shahaf
  2018-12-16 17:41       ` Peter Stephenson
  2018-12-16 19:15       ` Joey Pabalinas
  0 siblings, 2 replies; 7+ messages in thread
From: Daniel Shahaf @ 2018-12-16 11:54 UTC (permalink / raw)
  To: Joey Pabalinas; +Cc: Zsh Workers Mailing List

Joey Pabalinas wrote on Sat, Dec 15, 2018 at 16:01:27 -1000:
> On Sun, Dec 16, 2018 at 01:53:10AM +0000, Daniel Shahaf wrote:
> > Joey Pabalinas wrote on Sat, 15 Dec 2018 10:26 -1000:
> > > This is fairly innocuous behavior and is POSIX-compliant, so document
> > > this odd edge case rather than risk regressions attempting to change
> > > the lexer/parser code.
> > 
> > If preventing regressions is your goal, why not add a regression test using this syntax?
> 
> Sorry, maybe my commit message was a bit unclear. I meant instead of
> trying to poke at the parser/lexer code to make the behavior match the
> documentation, I figured it's easier to just do it the other way and
> document the weird edge case.
> 
> Sorry for the ambiguity (and the double send, forgot to CC the list),

The double send is my fault, not yours.  It is I who replied off-list in
the first place.

> should I revise the commit description?

Let me begin by saying I'm not familiar enough with the parser to have
an opinion on whether it would be better to have change the docs to
match the code, or change the code to match the docs, or leave this as
an implementation detail that's subject to change.

All that said, I'm not too bothered by the grammar of the log message
(which is now explained in this thread anyway).  I'd sooner suggest
changes to the new text:

> +++ b/Doc/Zsh/grammar.yo
> @@ -185,11 +185,12 @@ cindex(loops, for)
>  item(tt(for) var(name) ... [ tt(in) var(word) ... ] var(term) tt(do) var(list) tt(done))(
>  where var(term) is at least one newline or tt(;).
>  Expand the list of var(word)s, and set the parameter
>  var(name) to each of them in turn, executing
>  var(list) each time.  If the tt(in) var(word) is omitted,
> -use the positional parameters instead of the var(word)s.
> +use the positional parameters with a var(term) implicitly
> +appended instead of the var(word)s.
>  

Two issues here:

1. The docs of var(term) are spread across the first and last sentence.

2. Adding a side remark about var(term) to the last sentence may obscure
that sentence's primary point about the fallback to positional
parameters.

So, perhaps something like this (relative to master):

-where var(term) is at least one newline or tt(;).
 Expand the list of var(word)s, and set the parameter
 var(name) to each of them in turn, executing
-var(list) each time.  If the tt(in) var(word) is omitted,
+var(list) each time.  If the `tt(in) var(word)' is omitted,
 use the positional parameters instead of the var(word)s.
+
+var(term) should be one or more newline or tt(;), and is optional if
+the `tt(in) var(word)' is omitted.

But let's wait for someone familiar with the parser to opine on the
proposed strategic direction ("document the parser's behaviour") before
we spend too much time on implementing that.

>  More than one parameter var(name) can appear before the list of
>  var(word)s.  If var(N) var(name)s are given, then on each execution of the
>  loop the next var(N) var(word)s are assigned to the corresponding
>  parameters.  If there are more var(name)s than remaining var(word)s, the

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted
  2018-12-16 11:54     ` Daniel Shahaf
@ 2018-12-16 17:41       ` Peter Stephenson
  2018-12-16 19:15       ` Joey Pabalinas
  1 sibling, 0 replies; 7+ messages in thread
From: Peter Stephenson @ 2018-12-16 17:41 UTC (permalink / raw)
  To: Zsh hackers list

On Sun, 2018-12-16 at 11:54 +0000, Daniel Shahaf wrote:
> But let's wait for someone familiar with the parser to opine on the
> proposed strategic direction ("document the parser's behaviour")
> before
> we spend too much time on implementing that.

I can't imagine anyone is going to want to change the parser now: as
Joey said, it's not actually a problem.

It's related to the various forms of alternative syntax (somewhat more
convenient for users than they are for developers).

pws


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted
  2018-12-16 11:54     ` Daniel Shahaf
  2018-12-16 17:41       ` Peter Stephenson
@ 2018-12-16 19:15       ` Joey Pabalinas
  2018-12-16 19:41         ` Bart Schaefer
  1 sibling, 1 reply; 7+ messages in thread
From: Joey Pabalinas @ 2018-12-16 19:15 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Joey Pabalinas, Bart Schaefer, Zsh Workers Mailing List

[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]

On Sun, Dec 16, 2018 at 11:54:08AM +0000, Daniel Shahaf wrote:
> Let me begin by saying I'm not familiar enough with the parser to have
> an opinion on whether it would be better to have change the docs to
> match the code, or change the code to match the docs, or leave this as
> an implementation detail that's subject to change.

Agreed, that's probably a good idea.

> All that said, I'm not too bothered by the grammar of the log message
> (which is now explained in this thread anyway).  I'd sooner suggest
> changes to the new text:
> 
> > +++ b/Doc/Zsh/grammar.yo
> > @@ -185,11 +185,12 @@ cindex(loops, for)
> >  item(tt(for) var(name) ... [ tt(in) var(word) ... ] var(term) tt(do) var(list) tt(done))(
> >  where var(term) is at least one newline or tt(;).
> >  Expand the list of var(word)s, and set the parameter
> >  var(name) to each of them in turn, executing
> >  var(list) each time.  If the tt(in) var(word) is omitted,
> > -use the positional parameters instead of the var(word)s.
> > +use the positional parameters with a var(term) implicitly
> > +appended instead of the var(word)s.
> >  
> 
> Two issues here:
> 
> 1. The docs of var(term) are spread across the first and last sentence.

Yes, that is a bit awkward. I should find a better way to organize that.

> 2. Adding a side remark about var(term) to the last sentence may obscure
> that sentence's primary point about the fallback to positional
> parameters.
> 
> So, perhaps something like this (relative to master):
> 
> -where var(term) is at least one newline or tt(;).
>  Expand the list of var(word)s, and set the parameter
>  var(name) to each of them in turn, executing
> -var(list) each time.  If the tt(in) var(word) is omitted,
> +var(list) each time.  If the `tt(in) var(word)' is omitted,
>  use the positional parameters instead of the var(word)s.
> +
> +var(term) should be one or more newline or tt(;), and is optional if
> +the `tt(in) var(word)' is omitted.

Aha, optional works great here.


> But let's wait for someone familiar with the parser to opine on the
> proposed strategic direction ("document the parser's behaviour") before
> we spend too much time on implementing that.

But again agreed, I'll wait for someone who knows the parser well (Bart
maybe?) to chime in before I cook up a v2.

-- 
Cheers,
Joey Pabalinas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted
  2018-12-16 19:15       ` Joey Pabalinas
@ 2018-12-16 19:41         ` Bart Schaefer
  2018-12-16 22:00           ` Joey Pabalinas
  0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2018-12-16 19:41 UTC (permalink / raw)
  To: Joey Pabalinas, Daniel Shahaf, Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Sun, Dec 16, 2018, 11:15 AM Joey Pabalinas <joeypabalinas@gmail.com
wrote:

>
> But again agreed, I'll wait for someone who knows the parser well (Bart
> maybe?) to chime in before I cook up a v2.
>

Refer to PWS's message on this thread.

I think in general the parser is the way it's intended to be, and unless
there's an actual, nontrivial bug or incompatibility with a standard, it
should be assumed that the doc is incomplete.

>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted
  2018-12-16 19:41         ` Bart Schaefer
@ 2018-12-16 22:00           ` Joey Pabalinas
  0 siblings, 0 replies; 7+ messages in thread
From: Joey Pabalinas @ 2018-12-16 22:00 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Joey Pabalinas, Daniel Shahaf, Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Sun, Dec 16, 2018 at 11:41:12AM -0800, Bart Schaefer wrote:
> On Sun, Dec 16, 2018, 11:15 AM Joey Pabalinas <joeypabalinas@gmail.com
> wrote:
> 
> >
> > But again agreed, I'll wait for someone who knows the parser well (Bart
> > maybe?) to chime in before I cook up a v2.
> >
> 
> Refer to PWS's message on this thread.
> 
> I think in general the parser is the way it's intended to be, and unless
> there's an actual, nontrivial bug or incompatibility with a standard, it
> should be assumed that the doc is incomplete.

Cool, thanks for clearing that up. I'll spin a v2 in a bit then.

-- 
Cheers,
Joey Pabalinas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-15 20:26 [PATCH] zshmisc(1): document implicit append of `term` when `in word` is omitted Joey Pabalinas
     [not found] ` <1544925190.621790.1610325216.065C6F48@webmail.messagingengine.com>
2018-12-16  2:01   ` Joey Pabalinas
2018-12-16 11:54     ` Daniel Shahaf
2018-12-16 17:41       ` Peter Stephenson
2018-12-16 19:15       ` Joey Pabalinas
2018-12-16 19:41         ` Bart Schaefer
2018-12-16 22:00           ` Joey Pabalinas

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/ public-inbox