Am So., 6. Nov. 2022 um 17:57 Uhr schrieb John Cowan <[email protected]>: > > LGTM. > > On Sun, Nov 6, 2022 at 11:49 AM Marc Nieper-Wißkirchen > <[email protected]> wrote: >> >> Am So., 6. Nov. 2022 um 16:57 Uhr schrieb Marc Nieper-Wißkirchen >> <[email protected]>: >> > >> > Am So., 6. Nov. 2022 um 16:54 Uhr schrieb John Cowan <[email protected]>: >> > > >> > > >> > > >> > > On Sun, Nov 6, 2022 at 6:00 AM Marc Nieper-Wißkirchen >> > > <[email protected]> wrote: >> > > >> > >> Fluids have been added to the latest version in my personal repository. >> > > >> > > >> > > To improve interoperability, it would be good to add operations to make >> > > a fluid from an existing parameter object and to extract the parameter >> > > object from an existing fluid. I suggest the names "fluidify" (which is >> > > an unusual word, but standard) and "fluid-parameter". >> >> So, >> >> (fluid-parameter <fluid>) >> >> has to be syntax because a fluid is a syntactic entity. >> >> The same is valid for "fluidify" ("verflüssigen" in German). It has >> to bind a fluid because, at runtime, a fluid is not a value. >> >> What syntax did you have in mind? >> >> Akin to SRFI 212 ("alias"), we can have >> >> (fluidify <fluid> <param-expr>) >> >> which binds <fluid> to the (!) underlying fluid of <param-expr>. >> Therefore, no "define-" because there would be no new fluid created: >> >> (define p (make-parameter 'initial)) >> (fluidify x p) >> (fluidify y p) >> (free-identifier=? x y) ; => #t >> (eqv? (fluid-parameter x) p)) >> (eqv? (fluid-parameter y) p)) >> >> Comments?
When I just began to implement it, I noticed that it could not work. The problem is that there cannot be "the" underlying fluid of the value of <param-expr> (because the parameter could have been created anywhere). So a new fluid (but with the same underlying parameter) has to be created by "fluidify". So let me change the syntax to bind a fluid to (define-syntax x (fluidify p)) and, analogously, (let-syntax ([x (fluidify p)]) ...)
