From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 22:57:16 2022 Received: (at 56799) by debbugs.gnu.org; 14 Aug 2022 02:57:16 +0000 Received: from localhost ([127.0.0.1]:35489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN3oS-0006MZ-9S for submit@debbugs.gnu.org; Sat, 13 Aug 2022 22:57:16 -0400 Received: from mail-qv1-f47.google.com ([209.85.219.47]:44972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN3oO-0006MK-DB for 56799@debbugs.gnu.org; Sat, 13 Aug 2022 22:57:15 -0400 Received: by mail-qv1-f47.google.com with SMTP id mk9so3294019qvb.11 for <56799@debbugs.gnu.org>; Sat, 13 Aug 2022 19:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=lIiFCSz7ztpqlVQcDLMWhDR7J/KCzdePaZ1dwqOewGQ=; b=MBnZmHxngZ5DRaUTkNoulbkVfyXsJpkLzeqGg/X5F5q+Uhkj0dbKdqs2VaGI7eHbLT RHSEUTaxhg+Rrkzjh186kpaM+3Q7AjUlYOimOe4alLfYCMO9+mieTqGpP3zV4TDGS2uj nr3fvrmIQHJMz/OPmFCY0iAkZLJHfLyfzMGqkS34IvBShliGTjl8hbo8RF1qglit8kkB 4tE8CyCWJoeGPTk0sdha/cfEfy9LShxZ3SufBj+MVPiTgPYR+U+LwVuITzCuzLUazdHn ejex+wk1Ja0gzwWFjnbMo6NchFcLMutVslGdqLeMZ+eB73guOHwwqgm4f52FkOVux9E2 H7xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=lIiFCSz7ztpqlVQcDLMWhDR7J/KCzdePaZ1dwqOewGQ=; b=QPOrI+kOAILijJdXQrT+Rz/0HS5f9wjf4OJi905dBwReO4cCbqZHOZj+gGjemHIVOB P2MWW59uLnbSygQw6TqlGwXbdCb5Qi1ogck96uRJkfAZha7x3XFvhz6j7rsvV8VPcZlr GJr0DZ1eh1qXVNuHK69eGznjVDDyvERCYIS3pgxcr5gU63si9mqQU8CbFHzJ8O3ZjJMK mke+JIliu4/LtDxxDwHd4rMqXO3tjOb0vPdhqc9iL5zJsrvYUcVwkaU67zJ2fmO5fYoG m1ODH//f6V1GOrPyUV5MaVNAZMpL30S9XCsLny/6kjhxKjgo/MuhsBdZpeSlRyxZemLc a0Pw== X-Gm-Message-State: ACgBeo3ERZQKWpfBEasQ5TIy5Dls215NIqXOAcSMXCZzzLWyvmcjLiK2 rA49eR9soXEL2euvhOY181zBmsn9RuI= X-Google-Smtp-Source: AA6agR7mc17D21yiLO+THyuxNOEaI5ne3tBpnQyMm3xpnx7eqGGM0utlF95hkc8YX6r0ypxLyz9+lQ== X-Received: by 2002:a0c:9c48:0:b0:473:5e9e:741 with SMTP id w8-20020a0c9c48000000b004735e9e0741mr8949441qve.63.1660445826522; Sat, 13 Aug 2022 19:57:06 -0700 (PDT) Received: from hurd (dsl-205-233-125-72.b2b2c.ca. [205.233.125.72]) by smtp.gmail.com with ESMTPSA id b13-20020ac8678d000000b0034300e35487sm4873055qtp.54.2022.08.13.19.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Aug 2022 19:57:06 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> <87ilmwd57k.fsf@gmail.com> Date: Sat, 13 Aug 2022 22:57:05 -0400 In-Reply-To: (Attila Lendvai's message of "Sat, 13 Aug 2022 16:47:05 +0000") Message-ID: <87k07bbkhq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Attila, Attila Lendvai writes: [...] >> prepare a patch for the other things mentionned here (an exported >> symbol). Thanks! > i started implementing your suggestions, including the replacement of > the scattered usage of (eq? 'unset ...) pattern. what i found is that > the code is not very readable using MAYBE-VALUE-SET?, or at least not > for me. > > first, it negates the boolean logic everywhere in the current code > (i.e. larger diff, and/or the use of (if (not ...) a b)). > > and an example wrt readability: > > (if (maybe-value-set? field-default) > field-default > (configuration-missing-default-value ...) > > a value is never set, only places can be set to some value. It's not clear to me why you think the above is less readable; in the code I had to touch, the maybe-value-set? was more natural, as the cases I dealt with often tested for (not (eq? 'unset ...)), so reversing the logic allowed getting rid of the negation. See https://issues.guix.gnu.org/57168#13 for example. > > would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? unset-value? sounds like an action; so I'd name it 'maybe-value-unset?'; but as I wrote above I don't really see the benefit/like the idea. Thanks for working on it! Maxim