Re: Another push on declarednull branch

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Dec 28, 2020 at 1:46 PM Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
>
> On Mon, Dec 28, 2020 at 2:54 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > Would it make more sense as PM_IMPLICIT, so PM_NULL = (PM_IMPLICIT|PM_UNSET)?
>
> It's still the same problem isn't it? Why does typeset turn on
> PM_IMPLICIT, and unset off?

Typeset turns on PM_IMPLICIT because there's nowhere else that needs to.

Unset turns it off because the variable explicitly ceases to exist;
only its scope remains, if it had one.

> Moreover, implicit what?

Implicit(ly) whatever-other-flags-are-there.

> The true meaning is PM_UNSET_BUT_VALID, because the only time this
> flag does something is when PM_UNSET is on.

I don't think "valid" is a significantly more accurate description.
$thing is "valid" whether or not you've declared "typeset thing".

Anyway, I conceived PM_DECLARED (now for this discussion PM_IMPLICIT)
as having a meaning independent of PM_UNSET; for example
PM_IMPLICIT|PM_INTEGER means that if you assign to the variable, the
value is interpreted as a number.

That was before I realized that "unset foo" forgets everything about
"foo" except its scope.  That is, I began from the position that

  typeset -f foo
  unset foo
  foo=0.3

needed to resurrect foo as a float rather than a string ... but it
doesn't, in bash/ksh.  Hence unset must erase PM_IMPLICIT along with
everything else.

> I think that's a clear sign the logic is not correct.
>
> It's the other way around

Unfortunately given the bitwise implementation that condition is much
more complicated to test for; the reversal is for convenience.  Zsh is
full of bitfield-like booleans that mean nothing unless combined with
other such booleans.