Re: One more named reference scoping thing

Hi Bart,

Sorry for the late reply, I'm spending way too much on the first of my two promised posts, which gets longer and longer :-( but on the bright side I think that it also allowed me to find some good examples and rationales on why to do things a certain way. I hope that I can send a first version in about 24 hours. It will most likely only discuss typeset without -u. However, I think that it may still address some of the questions that you raise here.

For now, just two very quick answers.

The question is, is this OK? Or should return from i have set the
scope all the way to g? That has different side-effects in other
circumstances.

I think that I have an example without -u that exhibits a similar behavior, probably for the same reason. I think that the latter or something more similar to the latter should be done. I will have more explanation in my post.

Thinking further about this, I think a better solution is that when a
referent goes out of scope, the reference loses the -u property along
with it, and just becomes a "normal" named reference that moves to
lower levels as the scopes unwind.

I will have to have a closer look at this but my first impression is that the -u property should be kept, actually for the same rationale as the one for the change above.

Philippe

On Thu, May 8, 2025 at 8:35 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

On Wed, May 7, 2025 at 4:03 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> Thinking further about this, I think a better solution is that when a
> referent goes out of scope, the reference loses the -u property along
> with it, and just becomes a "normal" named reference that moves to
> lower levels as the scopes unwind.

As a last (?) remark about this, let me show the difference in the "-u
6" test result if this change is made.

[...]
i:1: rs= - ra= - rs1= - ra1=
i:2: rs=h - ra=h - rs1=h - ra1=h
j:1: rs=h - ra=h - rs1=h - ra1=h
j:2: rs=h - ra=h - rs1=h - ra1=h
i:3: rs=h - ra=h - rs1=h - ra1=h
k:1: rs=h - ra=h - rs1=h - ra1=h
k:2: rs=h - ra=h - rs1=h - ra1=h
-h:3: rs=g - ra=g - rs1=g - ra1=g
+h:3: rs=h - ra=h - rs1=h - ra1=h
k:1: rs=h - ra=h - rs1=h - ra1=h
k:2: rs=h - ra=h - rs1=h - ra1=h
-g:3: rs=f - ra=f - rs1=f - ra1=f
+g:3: rs=g - ra=g - rs1=g - ra1=g

The scope is set to h via initialization in i. Instead of skipping up
to scope g and then back to h, the reference stays at scope h until
the return to scope g. At that point instead of skipping to f, it
remains at g.

I think this makes much more sense than having the -u state reassert
itself a couple of times as the call chain unwinds, and is more
predictable than the alternative of skipping up some higher scope (in
this example, to scope g) and then sticking there.