Re: Another push on declarednull branch

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Mon, Dec 28, 2020 at 2:54 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Dec 28, 2020 at 12:23 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > On Sun, Dec 27, 2020 at 5:05 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > Alternate names for PM_DECLARED would be welcome.  If I could turn
> > > back time, I might use PM_NOTSET, and then PM_NULL ==
> > > (PM_NOTSET|PM_UNSET).
> >
> > However, I'm still not sure if those values make sense.
> >
> >   typeset var
> >   unset var
> >
> > In this case PM_UNSET is true, but PM_NOTSET is false. Why? No value
> > was ever assigned.
>
> 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?

Moreover, implicit what?

The true meaning is PM_UNSET_BUT_VALID, because the only time this
flag does something is when PM_UNSET is on. So you would have PM_NULL
= (PM_UNSET|PM_UNSET_BUT_VALID).

Then when you check PM_UNSET, you also check !PM_UNSET_BUT_VALID. A
simpler version would be PM_VALID, but when you assign a value,
PM_VALID would be turned off, which doesn't make sense.

I think that's a clear sign the logic is not correct.

It's the other way around:

PM_VALID = !PM_UNSET || PM_NULL

Then PM_NULL is set on typeset, and cleared with unset. Which makes sense.

Then, instead of checking PM_UNSET, you check !PM_VALID, or PM_UNSET
&& !PM_NULL.

> Naming is often a hard problem.  Speaking of which:
>
> > It's Felipe BTW.
>
> Apologies.  As someone who is often Burt/Bert/Bret/Brat, I know the annoyance.

No worries.

-- 
Felipe Contreras