Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: More named reference weirdnesses



If you would, please, back out the change to params.c from commit
e7163e69 and let me know if that changes the results of these tests to
behave the way you expect?

I have tried that. The result looks strictly worse. nr-test.zsh "" 2 produces the same result as before. Same for nr-test.zsh "" 4, which still exhibits the rebind after function call bug. For nr-test.zsh "" 0 and nr-test.zsh -u 0 all references are bogus and refer to the global variables instead of the more local ones, while before at least the references to the whole string and whole array referred to local variables.

Philippe


On Sun, May 4, 2025 at 5:19 PM Philippe Altherr <philippe.altherr@xxxxxxxxx> wrote:
Uh, a little late for that, isn't it?  Eric is already preparing the 5.10 release.

Sorry for that. Looking into named references was on my todo list for a long time. It's Eric's announcement that finally made me stop procrastinating. I know it's late but hopefully not too late to get this right. Since this is a new feature we certainly don't want to launch something whose specification must be changed soon after. My assessment is that the current implementation contains too many bugs to be released as is. More worryingly I think that the underlying specification and design goals are inadequate. I think that we could adopt an alternate specification that is both simpler and more useful than the current one and which I think would also be easier to implement and would present less corner cases.

I will publish a first post where I explain my understanding of the current specification, the problems that it poses, and the inconsistencies and bugs that I have discovered so far. Btw, if anyone has a more complete specification of the current implementation than "named references always expand parameters at the scope in which rname existed when ‘typeset -n’ was called" found in section 14.3.2, I would be very interested in seeing it.

In a second post I will describe my alternative specification with some examples and a rationale for preferring it over the current implementation.

Philippe



On Sun, May 4, 2025 at 2:02 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
On Sat, May 3, 2025, 5:07 PM Lawrence Velázquez <larryv@xxxxxxx> wrote:

Uh, a little late for that, isn't it?  Eric is already preparing the 5.10 release.

My commit e7163e69 has definitely changed something it shouldn't have, so I will try to revisit that soon if not tomorrow -- I can't recommend making the release with that commit still in place.  It fixes assignments with -u refs, but breaks dereferencing them if the referent is not in the immediately surrounding scope (which is why "make check" didn't flag an error).


Messages sorted by: Reverse Date, Date, Thread, Author