Re: [PATCH] First try of null typeset

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Wed, Dec 2, 2020 at 12:48 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> On Tue, Dec 1, 2020 at 1:13 AM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > This achieves most of what Bart Schaefer's version achieves, except no extra hacks are needed, and
> > integer and floats are not changed.
>
> Applying the change to integers and floats is one of the reasons I
> went in the direction I did.

Yes, I suspect that's the way it will eventually have to be done, but
others argued "typeset -i var" should initialize it to 0. So for those
my patch already does what is needed.

> What constitutes an "extra hack"?

The one I did to fix the PM_TIED case. I sent a patch for that.

> > In my opinion a separate concept of "null" variable will be needed, and should be separate from
> > PM_UNSET, since that changes a lot of behavior.
>
> I don't think it's possible to introduce a separate concept of "null"
> inside struct param without touching at least all the same places my
> branch already did, and probably others.  I would not be unhappy to be
> proven incorrect, but PM_UNSET already covers all the corner cases of
> what to do when a parameter should be treated as having no value,
> because that's how "local" followed by "unset" has always worked.

But as you showed the code assumes PM_UNSET variables don't exist.

I could comb through to code looking for instances PM_UNSET checks,
but I'm sure I will find some instances where the code doesn't do what
we want in that case.

> > Also, I don't think $empty[(i)] should return nothing, so probably paramsubst() would need to be tuned
>
> Agree.  This may be easier than it seems, because (i)/(I) already work
> on scalars: { thing="abcde"; print $thing[(I)] } yields 6.  I just ran
> out of time to dig further.

Yes, me too. My patch did the lazy thing too and just doesn't return anything.

> > Addtionally, this patch doesn't change the behavior of the private module.
>
> If by this you mean my branch changed something about "private" in a
> way that doesn't correspond to the rest of the changes, then I've
> overlooked something.

No. Your patch may be doing the desired behavior. Presumably if
"typeset var" doesn't set a value for var, then "private var"
shouldn't either.

I'm just saying my patch doesn't do that (although it probably should).

Cheers.

-- 
Felipe Contreras