Am Fr., 2. Jan. 2026 um 12:12 Uhr schrieb Eleanor Bartle
<xxxxxx@eleanor-nb.com>:
>
> This has all been very helpful, thankyou.

Thanks.

> I’ve been doing some thinking of my own, and I may have a solution for the resource problem in the presence of multi-shot continuations. It would require lower-level changes than SRFI 254, but by all accounts it does appear to be the canonical solution.
>
> The idea is presented in a paper (attached). In brief, values are assigned modes in addition to types, depending on whether they are confined to the current scope or not (local/global), are necessarily the only reference to their location or not (unique/aliased), and may be replicated in the future or not (many/once). Unmoded values have the maximally permissive mode global-aliased-many, for compatibility with existing code, but explicit annotations or (in a static language as presented in the paper) sufficiently advanced semantic analysis may tighten the mode bounds.

You probably mean that *variables* are assigned modes, don't you?

> I believe many of these concepts would also be applicable to a dynamic language like Scheme. I envision attributes checked and enforced at runtime, as values move across call boundaries and references are created and destroyed. In particular:

Does this mean that you envision predicates like the following two?

(once? OBJ)

or

(local? OBJ)

> A resource which is unique and local could be immediately destroyed when it goes out of scope

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)))))

(Of course, the once-logic should be abstracted away in some form
equivalent to CL's ‘unwind-protect’.)

The problem with this use of ‘dynamic-wind’ is that it doesn't play
well with effects modelled by delimited continuations whose handlers
are installed before the call to ‘call-with-local-resource’. (Haven't
I said that ‘dynamic-wind’ does not really have a place in a language
with delimited continuations?)

> A continuation with a unique or once value anywhere in its stack (including as a borrow) would automatically become once (one-shot)

"By anywhere in its stack", I assume you mean that the value in
question would be traced by a GC when handling the continuation (this
can be made precise). However, this means that ‘(once? CONTINUATION)’
would not be able to run in O(1) and would make it impractical. Note
that a mutation could make a continuation that fulfilled the ‘many?’
predicate into one that then fulfils the ‘only?’ predicate.

> A reset which captures a local value in its body would make the corresponding shift bind a local continuation

The same issues apply here.

Cheers,

Marc

> (One point not mentioned in the paper, but mentioned in a blog post about the paper, is the existence of additional intermediate modes: regional, for values which may escape one level of scope; exclusive, for values which may have other references in unreachable scopes; and separate, for values which may be used multiple times but only once at a time. I also have my own idea of how to extend the mode system to mutability, but that’s a much more extensive change which I don’t think is compatible with Scheme.)
>
> I hope these ideas are of some value to you.
> Eleanor
>
> On 2 Jan 2026, at 18:25, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> In standard Scheme, something like
>
> (dynamic-wind
>  (lambda () ...)
>  thunk
>  (lambda () (close-file ...)))
>
> is problematic because ‘dynamic-wind’ is not CL's ‘unwind-protect’,
> and an error would occur if THUNK were entered a second time. You
> could code around it as follows, depending on your use case:
>
> (let ([closed #f])
>  (dynamic-wind
>    (lambda ()
>      (when closed (error ...)))
>
>    thunk
>    (lambda ()
>      (set! closed #t)
>      (close-file ...))))
>
> The reason d'être of ‘dynamic-wind’ is the implementation of the
> dynamic environment, not necessarily resource control. For more
> (historical) background, the following may be interesting to you:
> https://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrrs-1997/msg00008.html
>
> With delimited continuation, nothing changes much. When resources can
> only be claimed and disposed of once, their management is orthogonal
> to unwind handlers because the dynamic extent of procedure calls is
> not connected (as must be the dynamic extent of the availability of
> the resource). To manage such resources automatically, some hook into
> the GC is necessary (see SRFI 254, for example).
>
> Marc
>
> PS If you didn't deliberately exclude the list address from the reply
> to me, please forward your question and my answer to the list. Thanks.
>
> Am Do., 1. Jan. 2026 um 20:38 Uhr schrieb Eleanor Bartle
> <xxxxxx@eleanor-nb.com>:
>
>
> Thankyou for the reply.
>
> Follow-up question: under the new model, how does one deter the “re-winding” of the stack that occurs when a continuation is invoked multiple times? My understanding is that the dynamic-wind “before” thunk serves this purpose; is my understanding incorrect? If so, how does one prevent a continuation with file handles or such from being invoked multiple times?
>
> Eleanor
>
> On 1 Jan 2026, at 23:48, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> Hi!
>
> Thanks for the question.
>
> The model of SRFI 248 (which is deliberately simple and basic but rich
> enough to build more complex abstractions on top of it) is that there
> is basically just one type of effect. Whatever effect is raised, the
> innermost handler is called (and can move control to the next
> enclosing handler by reraising the effect), so one can detect every
> unwinding of the stack through
> ‘with-unwind-handler’/‘raise-continuable’ and thus implement a version
> of ‘dynamic-wind’ that works for delimited continuations.
>
> With delimited continuations, ‘call/cc’ is not really necessary any
> more (except for backward compatibility). As the unwinding occurring
> from instantiating a continuation K captured by ‘call/cc´ does not
> trigger any unwind handler, one still needs the legacy ‘dynamic/wind’
> as long as the legacy ‘call/cc’ exists. One could amend SRFI 248 by
> integrating ‘call/cc’ fully by demanding that instantiating K raises a
> condition object, which leads to triggering the unwind handlers. This
> is less conservative but probably The Right Thing.
>
> Marc
>
> Am Do., 1. Jan. 2026 um 04:24 Uhr schrieb Eleanor Bartle
> <xxxxxx@eleanor-nb.com>:
>
>
> Apologies for the noise. I’m a passive nerd, attempting to understand Scheme internals, enamoured by delimited continuations.
>
> One thing I don’t understand in this SRFI is how it would be able to dispense with dynamic-wind, were it not for call/cc. How does that come about? More precisely, why does the unwinding/rewinding of a delimited continuation not necessitate dynamic-wind, and why does that reason not apply to call/cc?
>
> Eleanor
>
>
>