ŹRÓDŁO Zmęczony faktem, że rozmowy z listy dyskusyjnej zakłócają porządek w mojej prywatnej korespondencji, postanowiłem wdrożyć system czytania list dyskusyjnych bazujący na archiwach public-inbox. Listy dyskusyjne są tradycyjnym sposobem grupowej komunikacji za pomocą elektronicznej poczty. Archiwa public-inbox są bazującą na repozytoriach git metodą na powielanie archiwów list dyskusyjnych i ich czytanie bez aktywnego zapisywania się na te listy. Istnieją narzędzia które dalej przekształcają te archiwa w lokalne skrzynki pocztowe, dzięki którym można przeglądać listy dyskusyjne zwykłym programem pocztowym.

ŹRÓDŁO W ramach środowiska RDE dla systemu Guix zdefiniowana jest usługa home-l2md-service-type instalująca program przetwarzający archiwa public-inbox. RDE jest uzupełnieniem Guix zawierającym szereg dodatkowych narzędzi dla programistów i zaawansowanych użytkowników.

ŹRÓDŁO Konfiguracja usług Guix używa dwóch rodzajów rekordów do organizacji danych. Rekordy Guile są standardowym rodzajem rekordów o prostej budowie i nieskomplikowanej funkcjonalności. Rekordy Guix są bardziej rozbudowane i umożliwiają wiele działań programowania obiektowego. Zasadniczą zaletą rekordu Guix jest obecność konstruktora syntaktycznego, która pozwala na używanie nazw pól tego rekordu w definicjach. Dzięki temu zbędne jest stosowanie argumentów pozycyjnych podczas definiowania typu zmiennej rekordu Guix.

---

(define home-l2md-service-type
  (gnu:services:service-type
    (name        'home-l2md)
    (extensions  (list l2md-home-xdg-configuration-files
                       l2md-home-shepherd
                       l2md-home-profile))
    (description "Install and configure L2md.")))

Zmienna typu gnu:services:service-type jest rekordem Guix. Dotychczas błędnie uważałem, że jest funkcją, która przekazuje konfigurację usługi z argumentu.

(define l2md-home-profile
  (gnu:services:service-extension
    gnu:home:services:home-profile-service-type
    l2md-profile-service))

(define l2md-home-shepherd
  (gnu:services:service-extension
    gnu:home:services:home-shepherd-service-type
    l2md-shepherd-service))

(define l2md-home-xdg-configuration-files
  (gnu:services:service-extension
    gnu:home:services:home-xdg-configuration-files-service-type
    l2md-configuration-files))

Zmienna typu gnu:services:service-extension jest rekordem Guile. Od razu widoczna jest pozycyjna natura przekazywanych argumentów.

(define (l2md-configuration-files config)
  ...)

(define (l2md-profile-service config)
  ...)

(define l2md-shepherd-service
  ...)

Kolejna warstwa definicji jest niezrozumiała dla mnie. Dotychczas widziałem jedynie definicje usług bez argumentu konfiguracji lub z jednym argumentem konfiguracji. Ten zbiór definicji sugeruje, że powinno być możliwe podanie większej liczby argumentów dla definicji usług przyjmujących taką większą liczbę. Po szeregu małych eksperymentów dochodzę do sprzecznej obserwacji.

(define-record-type <service>
  (make-service type value)
  service?
  (type       service-kind)
  (value      service-value))

(define-syntax service
  (syntax-rules ()
    "Return a service instance of TYPE.  The service value is VALUE or, if
omitted, TYPE's default value."
    ( (_ type value)
      (make-service type value))
    ( (_ type)
      (%service-with-default-value (current-source-location)
                                   type))))

(define (%service-with-default-value location type)
  ...)

Świadczy to o tym, że w każdej sytuacji rekord typu service musi zawierać jeden argument konfiguracji. Niektóre definicje typów usług zawierają domyślne konfiguracje, i to w tej sytuacji widoczne były definicje bezargumentowe. W trakcie tych eksperymentów uświadomiłem sobie, że zmienna config używana w wielu rozszerzeniach innych usług odnosi się do tego samego obiektu konfiguracji.