Re: [PATCH] declarednull: rename DECLARED to NULL

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Sat, Jan 2, 2021 at 7:18 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Dec 28, 2020 at 2:13 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > This way the logic makes more sense:
> >
> >   typeset var <- NULL(on)
> >   unset var <- NULL(off)
> >   var='' <- NULL(off)
> >
> > NULL means: declared, no value, but still valid even with PM_UNSET.
> >
> > No functional changes.
>
> This is now getting a little bit weedy since only the names are under
> discussion, but ...

Yes. In this particular patch that's the only consideration, but I'm
using that only as the starting point. I'm still unsure about the rest
of the logic, but I haven't checked all the cases of PM_UNSET yet.

So, yes... For now.

> if we go all the way back to the original
> discussion about this, the point was that
>
> typeset var
> print ${var-unset}
>
> should output "unset".  Correct?

Yes, but that's only *one* of the considerations. It's still not
perfectly clear what "typeset -p var" should output. Using
"${var-unset}" is using loaded language.

If we use "${var-foo}", then yes; 100% under agreement.

> Consequently my thought was that PM_UNSET should be assigned for that
> case.  Using your terminology above, NULL(on) implies UNSET(on).  To
> me, that means that if there is a bit pattern named PM_NULL, it should
> include the bit pattern for PM_UNSET.  In retrospect I could just have
> used PM_NULL instead of PM_DECLAREDNULL but I was seeking to make it
> obvious that there were two bits in the pattern when it was used as a
> mask.

I mean NULL(on) imples "${var-foo}" returns "foo", yes.

> As one last stab at this, since neither PM_DECLARED nor PM_IMPLIED is
> satisfactory, what about PM_DEFAULT ?  And scrap PM_DECLAREDNULL for
> just PM_NULL.
>
> #define PM_NULL (PM_DEFAULT|PM_UNSET)
>
> This yields
>
> typeset var <- NULL(on) <- DEFAULT(on), UNSET(on)

Makes sense. I think it's debatable whether or not this is really
"unset" (what "typeset -p" var shows), but OK.

> unset var <- DEFAULT(off), UNSET(on) <- NULL(off)

Nope. The value hasn't changed, it still has the "default" value.

Now it's 100% sure it's really "unset" though.

> var='' <- DEFAULT(off), UNSET(off) <- NULL(off)

Yes. I agree with all these.


I think this is playing ring-around-the-rosy; you are trying to find a
word that signifies that no value has been assigned, even if the
variable is "set", but that's not "default", since the default can be
"". What we want is to change the default value from an empty string
(""), to a non-value, which in computer science usually is NIL. It's
not "default", it's not "designed"; it's "no value".

Doing "unset var" should not change the value in my opinion, but
that's probably another patch.

I think we should start by separating meaning from behavior, so how
about this script:

----
[[ -n ${ZSH_VERSION-} ]] && setopt posixbuiltins

function check {
  echo -n "$1: "
  test -n "${var+on}" && echo -n 'A(on)' || echo -n 'A(off)'
  echo -n ', '
  test -n "$(typeset -p var)" && echo -n 'B(on)' || echo -n 'B(off)'
  echo
}

function f {
  local var
  check 'local var'
  unset var
  check 'unset var'
}

f
----

With that script we get:

current zsh:
local var: A(on), B(on)
unset var: A(off), B(off)

bash:
local var: A(off), B(on)
unset var: A(off), B(on)

ksh:
local var: A(off), B(off)
unset var: A(off), B(off)

patched zsh (Bart):
local var: A(off), B(on)
unset var: A(off), B(off)

patched zsh (Felipe):
local var: A(off), B(on)
unset var: A(off), B(off)

So It seems your code and my code agree with the behavior of both A
and B. The only unknown is what A and B mean.

Agreed?

Cheers.

-- 
Felipe Contreras