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