GNU bug report logs - #75528
[PATCH 0/2] Add apcupsd

Previous Next

Full log

Message #80 received at 75528 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 75528 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: [bug#75528] [PATCH v3] services: Add power.
Date: Sun, 02 Mar 2025 14:26:58 +0900

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Hi Tomas,
>>
>> I was about to merge this, but I have one last (I promise!) question, see
>> below.
>
> No problem, I appreciate the review, it lead to higher code quality of
> this series.

:-)

>>
>> Tomas Volf <~@wolfsden.cz> writes:
>>
>> [...]
>>
>>> +(define apcupsd-service-type
>>> +  (service-type
>>> +   (name 'apcupsd)
>>> +   (description "Configure and optionally start the apcupsd.")
>>> +   (extensions (list (service-extension activation-service-type
>>> +                                        apcupsd-activation)
>>> +                     (service-extension shepherd-root-service-type
>>> +                                        apcupsd-shepherd-services)
>>> +                     (service-extension pam-root-service-type
>>> +                                        apcupsd-pam-extensions)))
>>> +   (compose identity)
>>> +   (extend (lambda (cfg lst)
>>> +             (fold (cut <> <>) cfg lst)))
>>
>> What does the above extend does?  I find the (cut <> <>) particularly
>> cryptic, as it's typically used to specialize procedures, which there
>> are none above.
>
> I consider the behavior of the default #f value for extend field to be
> unfortunate, so I prefer to specify extend for all my services.  Yet in
> this case there is no obvious thing to extend, so I opted for the
> extension to be a procedure, taking in the configuration and returning,
> possibly modified, configuration.

I see.  That's wasn't obvious to me.  If there's nothing to be
composed/extended, I think leaving the compose and extend fields to
their default values communicate this better.

> The (cut <> <>) is just a handy, more concise way to write
> (lambda (proc arg) (proc arg)).

I see.  I think my confusion also stemmed from the fact I can never
fully remember how extend/compose work until I look it up again :-).

> What are your thoughts here?  Should I just drop both compose and extend
> from here?  Or is it fine like this?

I'd just drop them.  If we discover a need later, we can add them back
in, ideally with users (other services) as self-documenting code.

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.