help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(current-module) and gexp, fighting for pretty code


From: Richard Sent
Subject: (current-module) and gexp, fighting for pretty code
Date: Wed, 28 Feb 2024 14:57:54 -0500

Hi Guix!

I have a setup where my operating system configurations are hosted in a
custom channel in dedicated modules, and I'm trying to get
unattended-upgrade-service working "cleanly" with it.

At present, I have an operating system that looks like

--8<---------------cut here---------------start------------->8---
(define-module (rsent machines droplets droplet-rampart)
  ;; ...
  #:export (droplet-rampart-system))

(define droplet-rampart-system
  (operating-system
   (inherit base-system)
   (services
    (cons*
     ;; ...
     (service unattended-upgrade-service-type
              (unattended-upgrade-configuration
               ;; ...
               (operating-system-expression
                ;; This way the operating-system itself will update,
                ;; not just imports
                #~(@ (rsent machines droplets droplet-rampart)
                droplet-rampart-system))))
     (operating-system-user-services base-system)))))
--8<---------------cut here---------------end--------------->8---

I'm trying to rewrite operating-system-expression to remove the
duplicate list of symbols, i.e. '(rsent machines droplets droplet-rampart).

I found that

--8<---------------cut here---------------start------------->8---
(operating-system-expression
 #~(module-variable #$(module-name (current-module))
    'droplet-rampart-system))
--8<---------------cut here---------------end--------------->8---

/nearly/ works, but (current-module) refers to (guile-user), not (rsent
...), in the generated unattended-upgrades.scm file.

I did find if I wrote

--8<---------------cut here---------------start------------->8---
(define module (current-module))
;; ...
#~(module-variable #$(module-name module) 'droplet-rampart-system)
--8<---------------cut here---------------end--------------->8---

The correct module name is used. However, this feels inelegant and I'd
rather just deal with the (admittedly very minor) module name
duplication.

Presumably the references ungexp captures are "module independent", for
lack of a better phrase, and are evaluated after we already left the
module. Ergo, capturing a reference to the current module /function/ is
meaningless, since the function will evaluate outside the scope of the
module I want to capture.

Is there a way I can have the best of both worlds? No module name
duplication and no extra variable creation? Some preexisting magical
variable I can capture that refers to the module I am currently in?

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]