[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: global vars and #:declarative? (was [critical bug] The set! doesn't
From: |
Dr. Arne Babenhauserheide |
Subject: |
Re: global vars and #:declarative? (was [critical bug] The set! doesn't work in indirect reference) |
Date: |
Thu, 19 Sep 2024 08:56:47 +0200 |
Nala Ginrut <nalaginrut@gmail.com> writes:
> I realized the #:declarative? can only be applied in the downstream modules
> of the module holding global vars.
This easy to hit complexity was the topic of my thread
"Making code compatible with different versions of Guile — #:declarative?"
How declarative currently works is a very painful gotcha that affects
one of the most elegant way of building Guile applications:
getting a live REPL and improving your code iteratively.
Chickadee uses that beautifully:
https://files.dthompson.us/docs/chickadee/latest/Live-Coding.html
Here’s an example of that:
https://www.draketo.de/software/chickadee-wisp.webm
https://www.draketo.de/software/wisp#chickadee-2022-10-08
But once this gets a bit more complex, you must litter your modules with
#:declarative? #f
otherwise your changes in the REPL have no effect at all.
For example entering a module with ,m to fix a bug there won’t be seen
by the actual running code.
And this is a breaking change in behavior (it actually broke working
code for me).
So I think that the default for user-modules should be non-declarative.
To improve performance nontheless, we could manually mark all modules
shipped with Guile as #:declarative? #t but change the default to #f.
> So the #:declarative? will affect the whole module and I have to put it
> everywhere that references the global vas.
>
> Maybe it'd be better if there's finer granularity control for each, like
> define-non-dclarative or else.
In the thread I mentioned, Maxime wrote that
(define (foo ...) ...)
(set! foo foo)
should have the effect of making foo non-declarative. I did not test
that yet, though.
> BTW. In my case, I want to implement the global var mutation. For such a
> case, if users don't want to put #:declarative? to affect the whole
> downstream modules, maybe the best way is to implement getter and setter
> inside the global var module.
I think that when we have to implement getters and setters for this,
that’s an indication of a design problem.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
signature.asc
Description: PGP signature