Why is "append" the activation service's "compose" procedure?

Why is "append" the activation service's "compose" procedure?

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

Hi,

This is our current definition of the activation-service-type (in (gnu
services)):

  (define activation-service-type
    (service-type (name 'activate)
                  (extensions
                   (list (service-extension boot-service-type
                                            gexps->activation-gexp)))
                  (compose append)
                  (extend second-argument)))

Note that the the append procedure is used as the "compose" procedure.
However, fold-services applies the "compose" procedure to a single list.
What happens when you apply the append procedure to a single list?  You
get the same list back:

  scheme@(guile-user)> (define mylist '(1 2 3))
  scheme@(guile-user)> (append mylist)
  $1 = (1 2 3)
  scheme@(guile-user)> (eq? mylist (append mylist))
  $2 = #t

The fold-services procedure always applies the "compose" procedure to a
single list.  So why does the activation-service-type use the append
procedure as its "compose" procedure?  Wouldn't it more accurately
reflect our intent if we used the identity procedure instead?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Why is "append" the activation service's "compose" procedure?

[Ludovic Courtès]

Hello,

Chris Marusich <cmmarusich@gmail.com> skribis:

> This is our current definition of the activation-service-type (in (gnu
> services)):
>
>   (define activation-service-type
>     (service-type (name 'activate)
>                   (extensions
>                    (list (service-extension boot-service-type
>                                             gexps->activation-gexp)))
>                   (compose append)
>                   (extend second-argument)))
>
> Note that the the append procedure is used as the "compose" procedure.
> However, fold-services applies the "compose" procedure to a single list.
> What happens when you apply the append procedure to a single list?  You
> get the same list back:
>
>   scheme@(guile-user)> (define mylist '(1 2 3))
>   scheme@(guile-user)> (append mylist)
>   $1 = (1 2 3)
>   scheme@(guile-user)> (eq? mylist (append mylist))
>   $2 = #t
>
> The fold-services procedure always applies the "compose" procedure to a
> single list.  So why does the activation-service-type use the append
> procedure as its "compose" procedure?  Wouldn't it more accurately
> reflect our intent if we used the identity procedure instead?

Yes, you’re right here as well.  :-)

‘boot-service-type’ has the same problem.

Can you fix both?

Thanks!

Ludo’.

Re: Why is "append" the activation service's "compose" procedure?

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> The fold-services procedure always applies the "compose" procedure to a
>> single list.  So why does the activation-service-type use the append
>> procedure as its "compose" procedure?  Wouldn't it more accurately
>> reflect our intent if we used the identity procedure instead?
>
> Yes, you’re right here as well.  :-)
>
> ‘boot-service-type’ has the same problem.
>
> Can you fix both?

I've done this in commit 7874e9e047219cce5ae339e57cd76f158bc19f63.

By the way, I noticed that the cups-service-type also uses "append" as
its "compose" procedure.  I think this is suspicious.  The comment in
the code says:

    ;; Extensions consist of lists of packages (representing CUPS
    ;; drivers, etc) that we just concatenate.
    (compose append)

However, that doesn't seem to be what's going on in the "extend"
procedure that follows it:

    ;; Add extension packages by augmenting the cups-configuration
    ;; 'extensions' field.
    (extend
     (lambda (config extensions)
       (cond
        ((cups-configuration? config)
         (cups-configuration
          (inherit config)
          (extensions
           (append (cups-configuration-extensions config)
                   extensions))))
        (else
         (opaque-cups-configuration
          (inherit config)
          (extensions
           (append (opaque-cups-configuration-extensions config)
                   extensions)))))))

Since there are no examples of extensions of the cups-service-type in
the Guix source tree, I'm not really sure what the intended behavior is.
If the "compute" procedure of any <service-extension> object that
extends the cups-service-type is intended to return a single package,
then my guess is that the "compose" procedure above should really be
identity, not append, in order to more accurately reveal the intent.
However, if the "compute" procedure is intended to return a list of
packages, then my guess is that the cups-service-type may not be
functioning as intended, and to fix it we will need to change the
"compose" procedure to concatenate.

Can someone who is familiar with the cups-service-type clarify what the
"compute" procedure of an extension of the cups-service-type is actually
supposed to return?  I've CC'd Andy, who originally added the
cups-service-type, in the hope that he might respond.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Why is "append" the activation service's "compose" procedure?

[Ludovic Courtès]

Hello Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> By the way, I noticed that the cups-service-type also uses "append" as
> its "compose" procedure.  I think this is suspicious.  The comment in
> the code says:
>
>     ;; Extensions consist of lists of packages (representing CUPS
>     ;; drivers, etc) that we just concatenate.
>     (compose append)

According to the comment, it should be ‘concatenate’ instead of
‘append’.

But like you write, it’s plausible that nobody tried to extend
‘cups-service-type’ so far, which is why we didn’t have any problems.

I think you can go ahead and make this change.

Thanks,
Ludo’.