Re: Hiding specials, and namerefs

On Mon, Jul 20, 2026 at 5:46=E2=80=AFPM Philippe Altherr
<[email protected]> wrote:
>
> I assume that's what pm->level =3D locallevel + 1 in function makezlepara=
ms achieves.

Yes.

> Now, speaking of special parameters, could anyone explain to me what is s=
upposed to happen if one declares without -h a local parameter with the sam=
e name as a special parameter?
>
> The documentation suggests that without -h the local parameter keeps the =
special effects of the enclosing special parameter.

That's the intention.  I believe the expectation is that one can e.g.
create a scoped $path that resets on exit from the scope.  There are
probably some specials that have since been introduced where this
doesn't make as much sense.  (Where "since" is a freakishly long time,
really.)

> How is that possible? How can the new parameter have its own state but st=
ill have the special effects? Is it because the local parameter reuses the =
same gsu but gets its own u?

If you look at createparam(), assigngetset() is not called for
specials, so yes, the local parameter re-uses the gsu.

> Or, is the special paramater's u being saved, reused and restored when th=
e local parameter goes away?

This happens the same way as with any other local.

> How is it possible to have multiple instances of the same special paramet=
er that each have their own state when there is a single C variable to back=
 them?
[...]
> This shows that there are two states but apparently both are somehow conn=
ected to the C home variable. Thanks to references, it's possible to access=
 both parameters from within the same scope. What is supposed to happen if =
we try that?

Honestly I don't think up-references to unhidden specials was ever
considered.  They should probably just be disallowed, there is no
provision for two accessible parameters to have the same backing
state.