Re: Hiding specials, and namerefs

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Jul 20, 2026 at 5:46 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> I assume that's what pm->level = locallevel + 1 in function makezleparams achieves.

Yes.

> Now, speaking of special parameters, could anyone explain to me what is supposed to happen if one declares without -h a local parameter with the same 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 still 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 the 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 parameter 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 connected 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.