zsh-workers
 help / color / mirror / Atom feed
* [BUG] zsh/param/private scoping error
@ 2021-09-01 11:49 Marlon Richert
  2021-09-01 14:09 ` Daniel Shahaf
  2021-09-01 14:39 ` Bart Schaefer
  0 siblings, 2 replies; 8+ messages in thread
From: Marlon Richert @ 2021-09-01 11:49 UTC (permalink / raw)
  To: Zsh hackers list

The following two functions are normally equivalent:

() { typeset -g tst }
() { tst= }

Both result in a global variable 'tst' being created. However when the
second function is called from a function that happens to declare a
private variable with the same name, it no longer creates a global
variable but instead aborts with an error:

% () { private tst; () { tst= } }
(anon):1: tst: attempt to assign private in nested scope
%

This is not how one would expect private variables to behave. Inside
the inner function, the private variable should be completely out of
scope and the `tst=` statement should result in the creation of a
global variable.

Note that the error above does not happens when there already exists a
global variable with the same name:

% typeset -g tst
% () { private tst; () { tst= } }
%


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

* Re: [BUG] zsh/param/private scoping error
  2021-09-01 11:49 [BUG] zsh/param/private scoping error Marlon Richert
@ 2021-09-01 14:09 ` Daniel Shahaf
  2021-09-01 16:21   ` Marlon Richert
  2021-09-01 14:39 ` Bart Schaefer
  1 sibling, 1 reply; 8+ messages in thread
From: Daniel Shahaf @ 2021-09-01 14:09 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Marlon Richert wrote on Wed, Sep 01, 2021 at 14:49:58 +0300:
> This is not how one would expect private variables to behave. Inside
> the inner function, the private variable should be completely out of
> scope and the `tst=` statement should result in the creation of a
> global variable.

Makes sense to me.  A regression test (one with the 'F' flag) would be
welcome, if you've got spare tuits.


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

* Re: [BUG] zsh/param/private scoping error
  2021-09-01 11:49 [BUG] zsh/param/private scoping error Marlon Richert
  2021-09-01 14:09 ` Daniel Shahaf
@ 2021-09-01 14:39 ` Bart Schaefer
  2021-09-01 16:03   ` Mikael Magnusson
  1 sibling, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2021-09-01 14:39 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Wed, Sep 1, 2021 at 4:51 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> % () { private tst; () { tst= } }
> (anon):1: tst: attempt to assign private in nested scope
> %
>
> This is not how one would expect private variables to behave.

But it's how variable scoping behaves in the shell language.  If I do

% () { local tst; () { tst=foo } }

Then it is the tst in the surrounding scope that gets altered, not the
global one.  If the inner function is INTENDED to create a global, it
should be using "typeset -g" explicitly.


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

* Re: [BUG] zsh/param/private scoping error
  2021-09-01 14:39 ` Bart Schaefer
@ 2021-09-01 16:03   ` Mikael Magnusson
  2021-09-01 16:11     ` Marlon Richert
  0 siblings, 1 reply; 8+ messages in thread
From: Mikael Magnusson @ 2021-09-01 16:03 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Marlon Richert, Zsh hackers list

On 9/1/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Wed, Sep 1, 2021 at 4:51 AM Marlon Richert <marlon.richert@gmail.com>
> wrote:
>>
>> % () { private tst; () { tst= } }
>> (anon):1: tst: attempt to assign private in nested scope
>> %
>>
>> This is not how one would expect private variables to behave.
>
> But it's how variable scoping behaves in the shell language.  If I do
>
> % () { local tst; () { tst=foo } }
>
> Then it is the tst in the surrounding scope that gets altered, not the
> global one.  If the inner function is INTENDED to create a global, it
> should be using "typeset -g" explicitly.

This seems weird to me, since private is stated to be "used to create
parameters whose scope is limited to the current function body, and
not to other functions called  by  the current function." If the
private parameter is not in scope, then any called functions should
behave as if it is not in scope, ie automatically create a parameter
scoped to whatever level is above the one that has the private.
(technically speaking, this is probably hard). If private parameters
are only compatible with code that runs without warnings under setopt
WARN_CREATE_GLOBAL, then we should document this.

-- 
Mikael Magnusson


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

* Re: [BUG] zsh/param/private scoping error
  2021-09-01 16:03   ` Mikael Magnusson
@ 2021-09-01 16:11     ` Marlon Richert
  2021-09-01 17:00       ` Mikael Magnusson
  0 siblings, 1 reply; 8+ messages in thread
From: Marlon Richert @ 2021-09-01 16:11 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Bart Schaefer, Zsh hackers list

On Wed, Sep 1, 2021 at 7:03 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 9/1/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> > On Wed, Sep 1, 2021 at 4:51 AM Marlon Richert <marlon.richert@gmail.com>
> > wrote:
> >>
> >> % () { private tst; () { tst= } }
> >> (anon):1: tst: attempt to assign private in nested scope
> >> %
> >>
> >> This is not how one would expect private variables to behave.
> >
> > But it's how variable scoping behaves in the shell language.  If I do
> >
> > % () { local tst; () { tst=foo } }
> >
> > Then it is the tst in the surrounding scope that gets altered, not the
> > global one.  If the inner function is INTENDED to create a global, it
> > should be using "typeset -g" explicitly.
>
> This seems weird to me, since private is stated to be "used to create
> parameters whose scope is limited to the current function body, and
> not to other functions called  by  the current function." If the
> private parameter is not in scope, then any called functions should
> behave as if it is not in scope, ie automatically create a parameter
> scoped to whatever level is above the one that has the private.
> (technically speaking, this is probably hard).

Also note that when _reading_ variables, the `private` keyword already
behaves like this, that is, the private variable is out of scope for
the inner function:

% () { ; private tst=bar; () { print tst=$tst } }
tst=
%
% tst=foo; () { ; private tst=bar; () { print tst=$tst } }
tst=foo
%


> If private parameters
> are only compatible with code that runs without warnings under setopt
> WARN_CREATE_GLOBAL, then we should document this.

That would largely defeat the purpose of private variables, wouldn't it? :)


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

* Re: [BUG] zsh/param/private scoping error
  2021-09-01 14:09 ` Daniel Shahaf
@ 2021-09-01 16:21   ` Marlon Richert
  0 siblings, 0 replies; 8+ messages in thread
From: Marlon Richert @ 2021-09-01 16:21 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Wed, Sep 1, 2021 at 5:10 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Marlon Richert wrote on Wed, Sep 01, 2021 at 14:49:58 +0300:
> > This is not how one would expect private variables to behave. Inside
> > the inner function, the private variable should be completely out of
> > scope and the `tst=` statement should result in the creation of a
> > global variable.
>
> Makes sense to me.  A regression test (one with the 'F' flag) would be
> welcome, if you've got spare tuits.

I was about to create one in V10private.ztst, when I noticed it
appears to exist already on lines 230 - 250. :)

 typeset -A hash_test=(top level)
 () {
  local -Pa array_test=(in function)
  local -PA hash_test=($array_test)
  () {
   print X ${(kv)hash_test}
   hash_test=(even deeper)
   {
     array_test+=(${(kv)hash_test})
   } always {
     print ${array_test-array_test not set} ${(t)array_test}
   }
  }
  print Y ${(kv)hash_test} Z $array_test
 }
 print ${(kv)hash_test} ${(t)array_test}
1:privates are not visible in anonymous functions, part 3
>X top level
>array_test not set
?(anon):4: array_test: attempt to assign private in nested scope
F:future revision will create a global with this assignment


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

* Re: [BUG] zsh/param/private scoping error
  2021-09-01 16:11     ` Marlon Richert
@ 2021-09-01 17:00       ` Mikael Magnusson
  2021-09-01 17:35         ` Bart Schaefer
  0 siblings, 1 reply; 8+ messages in thread
From: Mikael Magnusson @ 2021-09-01 17:00 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Bart Schaefer, Zsh hackers list

On 9/1/21, Marlon Richert <marlon.richert@gmail.com> wrote:
> On Wed, Sep 1, 2021 at 7:03 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>> If private parameters
>> are only compatible with code that runs without warnings under setopt
>> WARN_CREATE_GLOBAL, then we should document this.
>
> That would largely defeat the purpose of private variables, wouldn't it? :)

Ah, I misinterpreted one of the examples, I thought that this would
work as you expect:
() { private foo; () { typeset -g foo=bar } }
(while this wouldn't:
() { private foo; () { foo=bar } }
)

But in both cases it is an error (although only the latter prints a
message and aborts execution), and foo is not set globally.

In fact a typeset -g is needed on the global level before the function
using private is called, which seems impossible for the innermost
function to enforce.

-- 
Mikael Magnusson


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

* Re: [BUG] zsh/param/private scoping error
  2021-09-01 17:00       ` Mikael Magnusson
@ 2021-09-01 17:35         ` Bart Schaefer
  0 siblings, 0 replies; 8+ messages in thread
From: Bart Schaefer @ 2021-09-01 17:35 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Marlon Richert, Zsh hackers list

On Wed, Sep 1, 2021 at 10:00 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> Ah, I misinterpreted one of the examples, I thought that this would
> work as you expect:
> () { private foo; () { typeset -g foo=bar } }
> (while this wouldn't:
> () { private foo; () { foo=bar } }
> )
>
> But in both cases it is an error (although only the latter prints a
> message and aborts execution), and foo is not set globally.

Something else has changed since the implementation of private, I
think, because this is not what I expected:

top () { private foo=top; mid }
mid () { typeset -g foo=middle; bot }
bot () { print $foo }
functions -t top

% top
+top:0> private foo=top
+top:0> mid
+mid:0> typeset -g foo=middle
+mid:0> bot
bot: foo: attempt to assign private in nested scope

What makes the expansion of $foo in bot into an assignment?

> In fact a typeset -g is needed on the global level before the function
> using private is called, which seems impossible for the innermost
> function to enforce.

As you can see from the "F:" test Marlon quoted, this is something I
eventually intended to change.  It's rather complicated because of the
way locals are implemented as a LIFO at each individual named entry in
the parameter table, rather than a LIFO of parameter tables.  Even
without private, "typeset -g" only reaches as far upwards as the most
recent local declaration of the name.


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

end of thread, other threads:[~2021-09-01 17:36 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-01 11:49 [BUG] zsh/param/private scoping error Marlon Richert
2021-09-01 14:09 ` Daniel Shahaf
2021-09-01 16:21   ` Marlon Richert
2021-09-01 14:39 ` Bart Schaefer
2021-09-01 16:03   ` Mikael Magnusson
2021-09-01 16:11     ` Marlon Richert
2021-09-01 17:00       ` Mikael Magnusson
2021-09-01 17:35         ` Bart Schaefer

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ https://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

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

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