Fluids
Marc Nieper-Wißkirchen
(06 Nov 2022 11:00 UTC)
|
Re: Fluids
John Cowan
(06 Nov 2022 15:54 UTC)
|
Re: Fluids
Marc Nieper-Wißkirchen
(06 Nov 2022 15:57 UTC)
|
Re: Fluids
Marc Nieper-Wißkirchen
(06 Nov 2022 16:49 UTC)
|
Re: Fluids
John Cowan
(06 Nov 2022 16:57 UTC)
|
Re: Fluids
Marc Nieper-Wißkirchen
(06 Nov 2022 17:05 UTC)
|
Re: Fluids
Marc Nieper-Wißkirchen
(06 Nov 2022 17:09 UTC)
|
Re: Fluids Marc Nieper-Wißkirchen (06 Nov 2022 17:25 UTC)
|
I have now implemented and documented fluid-parameter and define-fluidified The updated spec and impl is in my personal repo. Am So., 6. Nov. 2022 um 18:09 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>: > > Am So., 6. Nov. 2022 um 18:05 Uhr schrieb Marc Nieper-Wißkirchen > <xxxxxx@nieper-wisskirchen.de>: > > > > Am So., 6. Nov. 2022 um 17:57 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > > > > > LGTM. > > > > > > On Sun, Nov 6, 2022 at 11:49 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: > > >> > > >> Am So., 6. Nov. 2022 um 16:57 Uhr schrieb Marc Nieper-Wißkirchen > > >> <xxxxxx@nieper-wisskirchen.de>: > > >> > > > >> > Am So., 6. Nov. 2022 um 16:54 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > >> > > > > >> > > > > >> > > > > >> > > On Sun, Nov 6, 2022 at 6:00 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> 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)]) > > ...) > > No, this is neither good as p should not be evaluated at expand-time.