Please excuse the delay.

Am So., 4. Jan. 2026 um 23:57 Uhr schrieb Eleanor Bartle
<xxxxxx@eleanor-nb.com>:
>
>
> 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.
>
>
> Yes, locations make the most sense. Please excuse me, I’m much more used to Lua terminology.
>
> 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?
>
>
> No, the predicates are pure, and actually thinking about it more, a once? predicate doesn’t make sense, as it would then consume the value. My interpretation of your original question was whether I foresaw the predicates doing the real work behind the macros, which I don’t: the modes would be tracked by the runtime itself, and mostly transparent to expanded code (modulo usage errors on mode violations).
>
> 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.
>
>
> “Duplication” means, say, the following:
>
> (define p (make-point x y))
> (define m p)
>
> There are now two variables that reference the location referred to by p when previously there was only one, hence p is no longer unique. Retrieving the value at a location does not count as duplication, only creating another reference to the same location.

The code

(let ([p (make-point x y)])
  (let ([m p])
    ...))

would show the same behaviour with respect to uniqueness, right? I am
asking because the semantics of ‘define’ are more complicated than the
quite simple semantics of ‘let’ and so the let-version will likely
less obscure the important points.

What about the following expression?

(let ([p (make-point x y)])
  (some-procedure p))

By the default Scheme semantics, new locations for ‘some-procedure’'s
(formal) arguments are allocated and initialised with the value of the
location ‘p’ denotes. But this would destroy uniqueness as well, so
the question would be whether uniqueness can realistically appear at
all.

It seems to me (and maybe you have already implied this) that you need
some lexical annotations to variables (in the same sense that static
types would be lexical annotations) to make any part of your proposal
work.

> 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.
>
>
> I’m not intimately familiar with call-with-port, but at a glance it does appear to have the semantics I describe. I’m apparently confused by dynamic-wind being an exception to every rule in Scheme. That said, there is still a potential issue of a port either not being closed in a timely manner or being closed prematurely, which this idea addresses.
>
> 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’.
>
>
> Ok, noted. It’s just dynamic-wind being contrarian again.
>
> I suppose there’s three ways the dynamic extent of a procedure can end: normal termination, exception unwinding, and shift. dynamic-wind activates on all three, call-with-port never activates unless it can prove that the dynamic extent will never be reentered; this idea activates on the first two but not the third.

Again, the basic exception mechanism of R[67]RS does not do any stack
unwinding. (This behaviour originates from SRFI 18. The rationale was
that unconditional unwinding the stack might be too costly in some use
cases and for some implementations. This rationale may no longer apply
to current implementations.)

> 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.
>
>
> I’ve thought about this some more, and I don’t think immutable bindings are necessary. That’s just the way Lua happens to do it, but in theory if the runtime knows when each individual scope ends, it can simply bump-allocate all local values originating in that scope, then clear them all immediately on scope end, running cleanup for the unique ones. This doesn’t require any tagging of local values, and I suppose it would mean uniqueness would be marked in the store rather than the environment.
>
> As for the semantics of once?, as above it doesn’t make sense as a predicate. The only sensible way to do it is to have such values declared as such lexically, and usage violation errors on improper use.
>
> It would be helpful if you could present a minimal language (think of
> a Scheme core) with well-defined semantics to illustrate your ideas.
>
>
> That would be helpful. Sadly I think it’s beyond my ability. As stated previously I am merely a passive nerd.

It is hard for me to discuss your proposal more deeply without some
concrete semantics.  It seems to me that what you propose is not
particularly tied to current standard Scheme but could be applied to
any (functional) programming language with lexical scoping.  It would,
therefore, make sense to discuss it detached from Scheme but for a
simpler language.

Best wishes,

Marc

>
> Eleanor
>