Re: global vars and #:declarative? (was [critical bug] The set! doesn't work in indirect reference)

"Dr. Arne Babenhauserheide" <[email protected]> Thu, 19 Sep 2024 08:56:47 +0200

Newsgroups	gmane.lisp.guile.user
Message-ID	<[email protected]>

Nala Ginrut <[email protected]> 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 (application/pgp-signature, 1.1 KB)