PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Daniel Shahaf]

As y'all recall, «functions -T» and «-t» set the XTRACE option for calls
to the named function.

With that in mind, in the following code:

[[[
f() g
g() :
functions -T f
functions -t f
f
]]]

Should XTRACE be on or off when g is run?  Or should an error be raised
before g is called?

And if -t were set first and -T second?

Cheers,

Daniel

Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Peter Stephenson]

> On 14 April 2021 at 16:03 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> As y'all recall, «functions -T» and «-t» set the XTRACE option for calls
> to the named function.
> 
> With that in mind, in the following code:
> 
> [[[
> f() g
> g() :
> functions -T f
> functions -t f
> f
> ]]]
> 
> Should XTRACE be on or off when g is run?  Or should an error be raised
> before g is called?
> 
> And if -t were set first and -T second?

The way the documentation is written:

  The flag -t turns on execution tracing for  this  function;
  the  flag -T does the same, but turns off tracing for any named (not
  anonymous) function called from the present one, unless  that  func‐
  tion  also  has  the  -t  or -T flag.

makes it sound as if turning off for called functions is more powerful behaviour,
in which case -T should always be used if specified.  But it doesn't actually
*say* that and could be rewritten anyway, so it's not much of a steer.  Having
one flag cause another to be ignored is pretty standard behaviour and relatively
straightforward to implement, though.

pws

Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Daniel Shahaf]

Peter Stephenson wrote on Wed, Apr 14, 2021 at 16:22:56 +0100:
> > On 14 April 2021 at 16:03 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > As y'all recall, «functions -T» and «-t» set the XTRACE option for calls
> > to the named function.
> > 
> > With that in mind, in the following code:
> > 
> > [[[
> > f() g
> > g() :
> > functions -T f
> > functions -t f
> > f
> > ]]]
> > 
> > Should XTRACE be on or off when g is run?  Or should an error be raised
> > before g is called?
> > 
> > And if -t were set first and -T second?
> 
> The way the documentation is written:
> 
>   The flag -t turns on execution tracing for  this  function;
>   the  flag -T does the same, but turns off tracing for any named (not
>   anonymous) function called from the present one, unless  that  func‐
>   tion  also  has  the  -t  or -T flag.
> 
> makes it sound as if turning off for called functions is more powerful behaviour,
> in which case -T should always be used if specified.  But it doesn't actually
> *say* that and could be rewritten anyway, so it's not much of a steer.  Having
> one flag cause another to be ignored is pretty standard behaviour and relatively
> straightforward to implement, though.

So, to be clear, you're proposing that setting either flag should unset
the other?  Sounds good to me; just making sure we're on the same page.

Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Peter Stephenson]

On Thu, 2021-04-15 at 16:21 +0000, Daniel Shahaf wrote:
> > > f() g
> > > g() :
> > > functions -T f
> > > functions -t f
> > > f
> > > 
> > > Should XTRACE be on or off when g is run?  Or should an error be raised
> > > before g is called?
> > > 
> > > And if -t were set first and -T second?
> > 
> > The way the documentation is written:
> > 
> >   The flag -t turns on execution tracing for  this  function;
> >   the  flag -T does the same, but turns off tracing for any named (not
> >   anonymous) function called from the present one, unless  that  func‐
> >   tion  also  has  the  -t  or -T flag.
> > 
> > makes it sound as if turning off for called functions is more
> > powerful behaviour, in which case -T should always be used if
> > specified.  But it doesn't actually *say* that and could be
> > rewritten anyway, so it's not much of a steer.  Having one flag
> > cause another to be ignored is pretty standard behaviour and
> > relatively straightforward to implement, though.
> 
> So, to be clear, you're proposing that setting either flag should unset
> the other?  Sounds good to me; just making sure we're on the same page.

Actually, the suggestion was even simpler --- leave them both set, but
just allow the -T behaviour to be used if both are set.  I think this is
how it's currently implemented, so it would just mean updating the
documentation.

However, actually unsetting the other one is entirely rational, too.
Which is least surprising depends how you think of the options: whether you
think of the option settings as strict alternatives, or you think of
them as two separate options that happen to have an overlapping function
of which you have to pick one.  So I can't really express a preference,
except to say if there's no good reason to change we should just
document what we have.

pws

Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Daniel Shahaf]

Peter Stephenson wrote on Thu, Apr 15, 2021 at 19:38:28 +0100:
> On Thu, 2021-04-15 at 16:21 +0000, Daniel Shahaf wrote:
> > > > f() g
> > > > g() :
> > > > functions -T f
> > > > functions -t f
> > > > f
> > > > 
> > > > Should XTRACE be on or off when g is run?  Or should an error be raised
> > > > before g is called?
> > > > 
> > > > And if -t were set first and -T second?
> > > 
> > > The way the documentation is written:
> > > 
> > >   The flag -t turns on execution tracing for  this  function;
> > >   the  flag -T does the same, but turns off tracing for any named (not
> > >   anonymous) function called from the present one, unless  that  func‐
> > >   tion  also  has  the  -t  or -T flag.
> > > 
> > > makes it sound as if turning off for called functions is more
> > > powerful behaviour, in which case -T should always be used if
> > > specified.  But it doesn't actually *say* that and could be
> > > rewritten anyway, so it's not much of a steer.  Having one flag
> > > cause another to be ignored is pretty standard behaviour and
> > > relatively straightforward to implement, though.
> > 
> > So, to be clear, you're proposing that setting either flag should unset
> > the other?  Sounds good to me; just making sure we're on the same page.
> 
> Actually, the suggestion was even simpler --- leave them both set, but
> just allow the -T behaviour to be used if both are set.  I think this is
> how it's currently implemented, so it would just mean updating the
> documentation.

Yes, that's how it's currently implemented.

> However, actually unsetting the other one is entirely rational, too.
> Which is least surprising depends how you think of the options: whether you
> think of the option settings as strict alternatives, or you think of
> them as two separate options that happen to have an overlapping function
> of which you have to pick one.  So I can't really express a preference,
> except to say if there's no good reason to change we should just
> document what we have.

Personally, I think it's actually easier to sell the "last one wins"
semantics: there's no logical reason why the behaviour of «functions -Tt
foo» should depend on which of -T/-t was implemented in a later version
of zsh, but every reason for the behaviour to depend on whether the call
passed -Tt or -tT.

That would, however, be an incompatible change ☹

I figured I'd write a test to at least ensure we don't change the
behaviour by accident (it would be too easy to change the if/else chain
that tests the bitflags), but ran into another question along the way.
Look at the first added test:

diff --git a/Test/E02xtrace.ztst b/Test/E02xtrace.ztst
index 10e8b8886..520b7745f 100644
--- a/Test/E02xtrace.ztst
+++ b/Test/E02xtrace.ztst
@@ -225,3 +225,38 @@
 >the definition didn't execute it
 >runs
 
+ f() g
+ g() :
+ functions -t f
+ f
+0:functions -t smoke test #1
+?+f:4> g
+?+g:4> :
+
+ f() g
+ g() { () : }
+ functions -t f
+ f
+0:functions -t smoke test #2
+?+f:4> g
+?+g:0> '(anon)'
+?+(anon):0> :
+
+ f() g
+ g() :
+ (
+  functions -T f
+  functions -t f
+  f
+ )
+ (
+  functions -t f
+  functions -T f
+  f
+ )
+0:ensure the behaviour  of 'functions -Tt f' doesn't change surreptitiously
+?+f:6> g
+?+f:11> g
+F:If this test fails, the new behaviour may be 
+F:workers/48591.
+

PS4 at the time is at its default value, %N:%i:

       %i     The line number currently being executed in the script, sourced
              file, or shell function given by %N. […]

       %N     The name of the script, sourced file, or shell function that zsh
              is currently executing, whichever was started most recently. […]

Given this, isn't the output «g:4» (last line of the first new test) wrong?

Thanks for the answer, Peter.

Cheers,

Daniel

Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Lawrence Velázquez]

Hi Daniel,

On Thu, Apr 15, 2021, at 4:58 PM, Daniel Shahaf wrote:
> I figured I'd write a test to at least ensure we don't change the
> behaviour by accident (it would be too easy to change the if/else chain
> that tests the bitflags), but ran into another question along the way.
> Look at the first added test:
> 
> diff --git a/Test/E02xtrace.ztst b/Test/E02xtrace.ztst
> index 10e8b8886..520b7745f 100644
> --- a/Test/E02xtrace.ztst
> +++ b/Test/E02xtrace.ztst
> @@ -225,3 +225,38 @@
>  >the definition didn't execute it
>  >runs
>  
> + f() g
> + g() :
> + functions -t f
> + f
> +0:functions -t smoke test #1
> +?+f:4> g
> +?+g:4> :
> +
> + f() g
> + g() { () : }
> + functions -t f
> + f
> +0:functions -t smoke test #2
> +?+f:4> g
> +?+g:0> '(anon)'
> +?+(anon):0> :
> +
> + f() g
> + g() :
> + (
> +  functions -T f
> +  functions -t f
> +  f
> + )
> + (
> +  functions -t f
> +  functions -T f
> +  f
> + )
> +0:ensure the behaviour  of 'functions -Tt f' doesn't change surreptitiously
> +?+f:6> g
> +?+f:11> g
> +F:If this test fails, the new behaviour may be 
> +F:workers/48591.
> +

Was this something you were planning on committing?

vq

Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Daniel Shahaf]

Lawrence Velázquez wrote on Sun, May 16, 2021 at 10:50:34 -0400:
> Was this something you were planning on committing?

Committed with an extra "F:" line.  Thanks.