[bug#49812] [PATCH] services: In MODIFY-SERVICES macro allow specifying a service by its name.

[bug#49812] [PATCH] services: In MODIFY-SERVICES macro allow specifying a service by its name.

[Brice Waegeneire]

This is specially useful with any services singleton created with
'simple-service' such as 'set-xorg-configuration'.

* doc/guix.texi (Service Reference)[modify-services]: Document support
  for specifying service by its name.
* gnu/services.scm (modify-services): Support specifying a service by
  its name in addition to its type.
---
 doc/guix.texi    | 14 +++++++-------
 gnu/services.scm |  5 +++--
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 2298d512a1..3b50976358 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -34319,20 +34319,20 @@ standard list combinators such as @code{map} and @code{fold} to do that
 common pattern.
 
 @deffn {Scheme Syntax} modify-services @var{services} @
-  (@var{type} @var{variable} => @var{body}) @dots{}
+  (@var{type-or-name} @var{variable} => @var{body}) @dots{}
 
 Modify the services listed in @var{services} according to the given
 clauses.  Each clause has the form:
 
 @example
-(@var{type} @var{variable} => @var{body})
+(@var{type-or-name} @var{variable} => @var{body})
 @end example
 
-where @var{type} is a service type---e.g.,
-@code{guix-service-type}---and @var{variable} is an identifier that is
-bound within the @var{body} to the service parameters---e.g., a
-@code{guix-configuration} instance---of the original service of that
-@var{type}.
+where @var{type-or-name} is a service type or name---e.g.,
+@code{guix-service-type} or @code{'guix}---and @var{variable} is an
+identifier that is bound within the @var{body} to the service
+parameters---e.g., a @code{guix-configuration} instance---of the
+original service of that type.
 
 The @var{body} should evaluate to the new service parameters, which will
 be used to configure the new service.  This new service will replace the
diff --git a/gnu/services.scm b/gnu/services.scm
index 2a8114a219..736ad2e4b9 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -303,8 +303,9 @@ singleton service type NAME, of which the returned service is an instance."
          (%modify-service svc clauses ...)))
     ((_ service)
      service)
-    ((_ svc (kind param => exp ...) clauses ...)
-     (if (eq? (service-kind svc) kind)
+    ((_ svc (kind-or-name param => exp ...) clauses ...)
+     (if (or (eq? (service-kind svc) kind-or-name)                      ;kind
+             (eq? (service-type-name (service-kind svc)) kind-or-name)) ;name
          (let ((param (service-value svc)))
            (service (service-kind svc)
                     (begin exp ...)))
-- 
2.32.0

[bug#49812] [PATCH] services: In MODIFY-SERVICES macro allow specifying a service by its name.

[Ludovic Courtès]

Hi,

Brice Waegeneire <brice@waegenei.re> skribis:

> This is specially useful with any services singleton created with
> 'simple-service' such as 'set-xorg-configuration'.

Could you show an example?  Services created by ‘simple-service’ &
co. are effectively anonymous; it’s a bit like a lambda.

> * doc/guix.texi (Service Reference)[modify-services]: Document support
>   for specifying service by its name.
> * gnu/services.scm (modify-services): Support specifying a service by
>   its name in addition to its type.

[...]

> +++ b/gnu/services.scm
> @@ -303,8 +303,9 @@ singleton service type NAME, of which the returned service is an instance."
>           (%modify-service svc clauses ...)))
>      ((_ service)
>       service)
> -    ((_ svc (kind param => exp ...) clauses ...)
> -     (if (eq? (service-kind svc) kind)
> +    ((_ svc (kind-or-name param => exp ...) clauses ...)
> +     (if (or (eq? (service-kind svc) kind-or-name)                      ;kind
> +             (eq? (service-type-name (service-kind svc)) kind-or-name)) ;name

As a general design pattern in Guix, “names” (symbols) are here for UI
and/or debugging purposes; they should not be used elsewhere because, by
definition, names are ambiguous.  Conversely, object references are
unambiguous and non-forgeable, so I prefer interfaces that avoid “names”
entirely.

I hope that makes sense!

Ludo’.