Thanks, I think that makes sense.
Is the `parameter * thread * parameterization -> box` part implemented as
something like a global weak-hash, or is it built directly into the stack
representation?
Continuing the other conversation for a moment with a code reference to
explain to my future self, or anyone else curious, what I meant by
"algebraic state effects". Here's a simple implementation with a couple
examples:
```
#lang racket/base
(require racket/control)
(struct state-parameter (tag)
#:property prop:procedure
(case-lambda
((self) (shift-at (state-parameter-tag self) k (lambda (x) ((k
x) x))))
((self v) (shift-at (state-parameter-tag self) k (lambda (_) ((k
(void)) v))))))
;; Analogous to make-parameter, but without a default value
(define (make-state-parameter)
(state-parameter (make-continuation-prompt-tag)))
(define-syntax state-parameterize*
(syntax-rules ()
((_ () body ...)
(let () body ...))
((_ ((e.p e)) body ...)
(let ((p e.p) (x e))
((reset-at (state-parameter-tag p)
(let ((result (begin body ...)))
(lambda (_) result)))
x)))
((_ (b bs ...) body ...)
(state-parameterize* (b) (state-parameterize* (bs ...) body ...)))))
(define-syntax state-parameterize-etc
(syntax-rules ()
((_ final () body ...)
(state-parameterize* final body ...))
((_ (final ...) ((e.p e) bs ...) body ...)
(let ((p e.p) (x e))
(state-parameterize-etc (final ... (p x)) (bs ...) body ...)))))
;; Analogous to parameterize
(define-syntax-rule (state-parameterize etc ...) (state-parameterize-etc ()
etc ...))
;; The same kind of single state example
(define P (make-state-parameter))
(define (show) (displayln (P)))
(define (inc) (P (+ 1 (P))))
(define K
(reset
(state-parameterize ((P 0))
(show)
(inc)
(shift k k)
(show)
(inc)
(P))))
(displayln "with algebraic state:")
(K) ; 2
(K) ; 2
(K) ; 2
;; An example with multiple states
(define R (make-state-parameter))
(define Q (make-state-parameter))
(define (show2) (displayln `(R: ,(R) Q: ,(Q))))
(define (inc2) (R (+ 1 (R))) (Q (- (Q) 1)))
(define J
(reset
(state-parameterize ((R 0) (Q 0))
(show2)
(inc2)
(shift k k)
(show2)
(inc2)
(list (R) (Q)))))
(displayln "with multiple algebraic states:")
(J) ; 2 -2
(J) ; 2 -2
(J) ; 2 -2
```
On Friday, July 30, 2021 at 11:04:09 AM UTC-4 Matthew Flatt wrote:
> At Sun, 25 Jul 2021 10:35:00 -0700 (PDT), Greg Rosenblatt wrote:
> > I was surprised that subsequent re-entries can observe modifications
> from
> > the earlier ones, since my mental model of dynamic parameters was that
> > their values were retrieved from a fresh dynamic calling context, whose
> > frames are copied each time the delimited continuation is invoked.
> > [...]
> > I'm also interested in the reasons behind the current design. Is there a
> > downside to storing parameter bindings directly on the stack, rather
> than
> > in a thread cell pointed to by the stack?
>
> I think I see what you mean here, but I also think that idea would run
> into trouble. A (delimited) continuation is invoked every time you
> return a value to a continuation, whether or not that continuation was
> captured by `call/cc`. Internally, in fact, the current continuation
> frequently gets reified and invoked through returns. I think it would
> create a bad interaction among features if a distinction were made
> between explicit (applying a captured continuation) and implicit
> (returning a value) continuation invocations.
>
> > I'd like to be able to resume that continuation in the same context
> > multiple times without observing modifications caused by other
> > resumptions. [...] But it looks like dynamic parameters actually rely
> > on a shared mutable cell, in this case a thread cell.
>
> Yes, parameters are based on a mapping
>
> parameter * thread * paramterizization -> box
>
> When you set or look up a parameter value, the thread part comes from
> `current-thread`, and the parameterization part comes from a
> continuation mark. So, that's why capture and restore within a thread
> sees the same box, but capture and restore of a continuation in a
> different thread gets a different box.
>
> I think you want to introduce a notion of "resume" that replaces the
> thread part of the mapping, plus a replacement notion of
> parameterization. That is, each time you resume, the applied
> continuation should extend one that maps an internal mark to the
> current resume. A replacement for `parameterize` would also install a
> mark (with a different key) to identify a "parameterization", while
> also mapping the parameter * parameterization * resume to a fresh box.
> When you look up a parameter value or mutate a parameter, the current
> mark for the resume and the current mark for the parameterization would
> let you find the right box.
>
> It may be best to have a "parameterization" specific to each
> "parameter" (i.e., a separate mark for each parameter), instead of
> aggregating them in the way `parameterize` does. In the case of threads
> and parameters, aggregation makes it easier to create a new thread that
> inherits the parameterization of the creating thread. But if you don't
> need that, aggregation also works less well with delimited continuation
> capture, because `parameterize` captures all parameter values and not
> just the ones that are set in the `parameterize` form.
>
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/1d037d3f-83e6-45b2-b215-ea574ed586dcn%40googlegroups.com.
