At first sight, Racket's behavior looks strange (tested with 8.2):
This expression
(let ((m (make-parameter 0))
(n (make-parameter 0)))
(define k
(parameterize ((m 1))
(call-with-continuation-prompt
(lambda ()
(parameterize ()
((call-with-composable-continuation
(lambda (k)
(lambda () k)))))))))
(k (lambda () (values (m) (n)))))
evaluates to the values 0 0. The following expression, however,
(let ((m (make-parameter 0))
(n (make-parameter 0)))
(define k
(parameterize ((m 1))
(call-with-continuation-prompt
(lambda ()
(parameterize ((n 1))
((call-with-composable-continuation
(lambda (k)
(lambda () k)))))))))
(k (lambda () (values (m) (n)))))
evaluates to the values 1 1.
The only difference is that the inner parameterization is not trivial.
It seems to be that each non-trivial parameterize installs a new
continuation mark (holding the complete new parameterization). This
is captured by c-w-c-c. However, when there is no non-trivial
parameterize, no continuation mark about parameterizations is
installed in the frames that are captured, and so reinstalling the
delimited continuation does not restore the relevant continuation
marks.
Actually, this model happens to coincide with my wording in SRFI 226:
"Conceptually, each continuation contains at least one otherwise
inaccessible parameterization continuation mark, whose value is a
parameterization. The parameterization of a continuation is the value
of the most recent parameterization continuation mark in the
continuation. The parameterization of the current continuation is the
current parameterization. The (current) parameterization can
conceptually be seen as part of the dynamic environment."
If I take this seriously, my sample implementation has to be corrected.
Am Fr., 18. Nov. 2022 um 20:57 Uhr schrieb Marc Nieper-Wißkirchen
<marc.nie...@gmail.com>:
>
> Here is an example using only the primitives:
>
> (let ((m (make-parameter 0)))
> ((parameterize ((m 4))
> (call-with-continuation-prompt
> (lambda ()
> ((call-with-composable-continuation
> (lambda (k)
> (abort-current-continuation (default-continuation-prompt-tag)
> (lambda () k))))))))
> m))
>
> In Racket, it evaluates to 0 and not to 4.
>
> Am Fr., 18. Nov. 2022 um 20:51 Uhr schrieb Shiro Kawai
> <shiro.ka...@gmail.com>:
> >
> > Racket v8.6 behaves the same way.
> >
> > On Fri, Nov 18, 2022 at 9:29 AM Shiro Kawai <shiro.ka...@gmail.com> wrote:
> >>
> >> I used Racket v7.2, and here's the full transcription. I'm going to check
> >> with the newest Racket.
> >>
> >> shiro@scherzo:~/src/srfi-226$ racket
> >> Welcome to Racket v7.2.
> >> > (require racket/control)
> >> > (define (print . xs) (for-each display xs) (newline))
> >> > (define m (make-parameter 0))
> >> > (define c #f)
> >> > (define (foo)
> >> (parameterize ((m 1))
> >> (reset
> >> (print 'a: (m))
> >> (shift k (print 'b: (m)) (set! c k))
> >> (print 'c: (m)))))
> >> > (define (bar)
> >> (parameterize ((m 2))
> >> (c #f)))
> >> > (foo)
> >> a:1
> >> b:1
> >> > (bar)
> >> c:2
> >>
> >>
> >> On Fri, Nov 18, 2022 at 9:26 AM Marc Nieper-Wißkirchen
> >> <marc.nie...@gmail.com> wrote:
> >>>
> >>> Thanks for the report, Shiro!
> >>>
> >>> I have to investigate Racket's behavior. In 11.3.2 of the Racket
> >>> reference, it says: "If a continuation is captured during the
> >>> evaluation of parameterize, invoking the continuation effectively
> >>> re-introduces the parameterization, since a parameterization is
> >>> associated to a continuation via a continuation mark (see Continuation
> >>> Marks) using a private key." This seems to be consistent with SRFI
> >>> 226 and its sample implementation, but not consistent with your Racket
> >>> experiments.
> >>>
> >>> Am Fr., 18. Nov. 2022 um 20:07 Uhr schrieb Shiro Kawai
> >>> <shiro.ka...@gmail.com>:
> >>> >
> >>> > It seems that there's a disagreement in how a delimited continuation
> >>> > captures dynamic environment, between Racket and srfi-226.
> >>> >
> >>> > Suppose the following code:
> >>> >
> >>> > ```
> >>> > (define (print . xs) (for-each display xs) (newline))
> >>> >
> >>> > (define m (make-parameter 0))
> >>> >
> >>> > (define c #f)
> >>> >
> >>> > (define (foo)
> >>> > (parameterize ((m 1))
> >>> > (reset
> >>> > (print 'a: (m))
> >>> > (shift k (print 'b: (m)) (set! c k))
> >>> > (print 'c: (m)))))
> >>> >
> >>> > (define (bar)
> >>> > (parameterize ((m 2))
> >>> > (c #f)))
> >>> > ```
> >>> >
> >>> > With srfi-226 (using reset/shift as given in the srfi) reference
> >>> > implementation on Chez, I get this:
> >>> >
> >>> > ```
> >>> > > (run foo)
> >>> > a:1
> >>> > b:1
> >>> > > (run bar)
> >>> > c:1
> >>> > ```
> >>> >
> >>> > With Racket racket/control, I get this:
> >>> >
> >>> > ```
> >>> > > (foo)
> >>> > a:1
> >>> > b:1
> >>> > > (bar)
> >>> > c:2
> >>> > ```
> >>> >
> >>> > I'm switching Gauche's internals to srfi-226 based model, and I noticed
> >>> > the difference---the current released version of Gauche (relying on
> >>> > dynamic-wind to handle parameterization) works like Racket, while the
> >>> > srfi-226 based version (using dynamic env chain to keep parameters)
> >>> > works like srfi-226 reference implementation.
> >>> >
> >>> > I think srfi-226 behavior is more consistent (when the delimited
> >>> > continuation is invoked, it restores the dynamic environment of the
> >>> > continuation of reset), but is there a plausible explanation of Racket
> >>> > behavior?
> >>> >
> >>> > This difference actually caused a compatibility problem of an existing
> >>> > application so I want to understand it fully.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
