Please excuse the many questions below, but I really would like to
understand your proposal thoroughly and not be left guessing.

Am Sa., 3. Jan. 2026 um 00:27 Uhr schrieb Eleanor Bartle
<xxxxxx@eleanor-nb.com>:
>
>
> You probably mean that *variables* are assigned modes, don't you?
>
>
> No, I do mean values. Tracking modes on variables doesn’t make much sense in a language with pervasive mutability, much less in a dynamic language. Runtime checks on values decreases compile-time accounting.

You were talking about the paper, which is about the statically typed
language OCaml.

That said, for Scheme, you probably want to ultimately assign the
modes to locations and not to values, don't you? For example, it
doesn't make much sense to talk about the value ‘5’ being once or the
symbol ‘foo’ being aliased. But it makes sense to talk about a vector
whose locations are in some sense special.

> Does this mean that you envision predicates like the following two?
>
> (once? OBJ)
>
> or
>
> (local? OBJ)
>
>
> I do, but the fundamental mechanics of it would be mostly in the environment, not in the predicates.

What does this mean? Only that the predicates are impure and rely on
global state/the dynamic environment, or do you mean something more
specific here?

> There would also be implicit checks for when a reference is duplicated, which would mark a unique or exclusive value as aliased and error on a once or separate value.

What do you mean by "reference is duplicated"? In Scheme, variables
reference locations that hold values. But duplicating cannot mean
retrieving the value stored in a location because then a ‘once’
value/location cannot be used at all.

> Can you be precise about what you mean here? By "going out of scope",
> do you mean that control leaves the region where the resource was
> allocated?
>
> Do you think of something like:
>
> (define (call-with-local-resource proc open close)
>  (let ([closed #f]
>         [resource (open)])
>    (dynamic-wind
>      (lambda ()
>        (when closed (assertion-violation ...)))
>      (proc resource)
>      (lambda ()
>        (set! closed #t)
>        (close resource)))))
>
>
> No, on two counts:
>
> By “going out of scope”, I mean the scope where it was declared ends via normal control flow or non-resumable exception, not when it’s captured in a continuation. Think Lua coroutines: to-be-closed values aren’t closed on yield, only on error or normal scope end. The point below would prevent this from happening multiple times.

I don't know Lua.

Do you mean semantics equivalent to the one of Scheme's
‘call-with-port’? Why is the way Scheme handles it with
‘call-with-port’ not sufficient?

Note that ‘raise’, ‘raise-continuable’, and ‘with-exception-handler’
do not change the control-flow. The basic exception mechanism in
Scheme depends on the dynamic environment but is otherwise orthogonal
to non-local control-flow.

> In my conception, this would be done automatically by the runtime, not by explicit dynamic-wind. There’s no dynamic-wind involved in this idea; capturing a continuation isn’t even considered to be “unwinding” in the traditional sense.

In traditional Scheme, capturing a continuation doesn't unwind the stack.

When I gave the above code with ‘dynamic-wind’, I didn't mean that
your idea involves ‘dynamic-wind’. I gave to ask whether your idea
would result in something with equivalent semantics of
‘call-with-local-resource’.

> However, this means that ‘(once? CONTINUATION)’ would not be able
>
> to run in O(1) and would make it impractical.
>
>
> It would be, if once? had to scan the whole stack to operate. I envision that the runtime could keep track of this when winding each individual frame, or perhaps when (not really, as above) “unwinding” to capture the continuation, and mark the continuation as once in the environment, thus allowing O(1) query and preventing it being invoked multiple times.
>
> Note that a mutation could make a continuation that fulfilled the ‘many?’
> predicate into one that then fulfils the ‘only?’ predicate.
>
>
> This is a genuine issue. It’s why Lua <close> values are also necessarily <const>. Perhaps that would be another condition of automatic cleanup; otherwise we defer to the GC, as usual.

If you only want to attach the attributes to hereditarily immutable
values, the operations could be O(1) at the expense of needing a
number of tagging bits in the underlying machine representation. But
this still leaves open the exact semantics of ‘once?’.

It would also need a move from a language with very few immutable
values to a language where most values are immutable for it to be
useful in practice.

>
> The same issues apply here.
>
>
> And the same solution as well. Whether a reset captures local values can be known at invocation time, and this information can be saved on the stack, to be later captured by the continuation.
>
> I suppose the crux of it is my idea involves a lot more runtime support and fewer primitive operations. Trying to implement it entirely within the existing environment model with only new primitives would indeed be a nightmare. I don’t think it’s a large or un-Scheme-like expansion, but it’s along a different axis than most ideas.

It would be helpful if you could present a minimal language (think of
a Scheme core) with well-defined semantics to illustrate your ideas.

Marc