SOURCE Tired of the fact, that mailing list discussions disrupt the order of my private correspondence, I resolved to implement a system for reading mailing lists based on public-inbox archives. Mailing lists are a traditional way of group communication with e-mail. Public-inbox archives are a method based on git repositories for replication and reading of mailing list archives without having to actively subscribe to the lists. There are tools which furthers transform these archives into local mail boxes, thanks to which mailing lists can be read with a typical mail client.

SOURCE In RDE environment for Guix system is a definition of home-l2md-service-type service which installs a program for transformation of public-inbox archives. RDE is an extension of Guix containing a number of additional tools for programmers and power users.

SOURCE Configuration of Guix services involves two kinds of records to organize data. Guile records are the standard kind of records with a simple structure and uncomplicated functionality. Guix records are more complex and enable many operations of object oriented programming. The main upside of a Guix record is the presence of a syntactic constructor, which allows use of this record’s field names in definitions. Thanks to this use of positional arguments is unnecessary while defining a variable of a Guix record type.

---

(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.")))

A variable of gnu:services:service-type type is a Guix record. Until now I mistakenly thought that it is a function which passes a service configuration from an argument.

(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))

A variable of type gnu:services:service-extension is a Guile record. Immediately visible is the positional nature of the passed arguments.

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

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

(define l2md-shepherd-service
  ...)

The next layer of definitions is not understandable to me. So far I have only seen service definitions with no configuration argument or with one configuration argument. This set of definitions suggests, that it should be possible to provide more arguments to service definitions accepting such bigger number of arguments. After a few small experiments I make a contradictory observation.

(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)
  ...)

This shows that a service type record must always contain one configuration argument. Some service type definitions contain default configuration and it is in this case that definitions without arguments were seen. During the experiments I realized that config variable used in multiple extensions of other services refers to the same configuration object.