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)

Re: Fluids Marc Nieper-Wißkirchen 06 Nov 2022 17:24 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.