From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 12:55:29 2022 Received: (at 56799-done) by debbugs.gnu.org; 1 Aug 2022 16:55:30 +0000 Received: from localhost ([127.0.0.1]:41507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIYhV-0005u0-GR for submit@debbugs.gnu.org; Mon, 01 Aug 2022 12:55:29 -0400 Received: from mail-qk1-f171.google.com ([209.85.222.171]:43945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIYhS-0005tm-TS for 56799-done@debbugs.gnu.org; Mon, 01 Aug 2022 12:55:28 -0400 Received: by mail-qk1-f171.google.com with SMTP id o21so8824897qkm.10 for <56799-done@debbugs.gnu.org>; Mon, 01 Aug 2022 09:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Cd/dNokSvI304DnT8HOfAIyBk2nGe89RPhSlV+HPxuU=; b=R/kSfZhYSMeG0HeTuU8QlPqAL1+pzt0v7tg7m0kIVvf2TwhOhau6dkxpUurQI/68wq xQrxnyuE3J1hZKgEKbdNAmSe+Bs8ioqbfralmkH09HgPskEgIvLJOqdc1SnWt2tuM6Vz r6c09kJ3qHILMxpWsjB9szR1xVGtEiWLIX4bczd4ky8BwdDEcBdgVifowkD1r+bHyzBG ddEvvBxTw+LQ5VwQNz1FVuvXHzKAGequsoW6GBUo/4/rgVSHqhkPIsU2bj7YoI+d0ZwY CyYE+luKpuMor5A0bV0d3gSDOI9KE+E+EadW6IMHxvKV0pvs964SxWWb5iWneacYfnQk qGnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Cd/dNokSvI304DnT8HOfAIyBk2nGe89RPhSlV+HPxuU=; b=SpZMXbAifsRegLknJt/UMfZAGoWM7edWHhRjeVZ0MHQ/IrvO3TiiaVCxJJ1QuqpK1T 6v7vOzRrtqJndI9u3N0sEOP+5v3mTNEziuzcFWUZMfOpjANxRvnKyU+NxzgBTNOucGr8 lYx+pjYaZupVns+M5ff/aeolrxI3sgXNzE8g9HNE9XdnhReXx2kiG25/foi2bOjFTr+4 czSQppxw+3dTHFH4pmhgL5gx81sfkbuZxEMe2j07omb2lbJWZ0D7/EnDSCkMk7DMHNB3 yTF/iI+RUhPRSRdgMxBbod5fzlNy8tjNlsT2/e07dwM9Fzu2E8Zyae3A4vgS8DHKT93k op7A== X-Gm-Message-State: AJIora9v6Nc87tJIblwL2/YNjD+mCfUdKPQFa1HlEFWiN9MwTTW/HAXU 3RuAP3OVDuXo3KheZEpU3CHqm+Y3AVhZ6w== X-Google-Smtp-Source: AGRyM1sSBtKmlUP9/ZakyKVhhX2iIJ3p07/F3e8h93VK5x8eFTsx5dIpr/1j6VEjcDuDIWNR9LgZag== X-Received: by 2002:ae9:efd8:0:b0:6b5:df92:dc3b with SMTP id d207-20020ae9efd8000000b006b5df92dc3bmr12591320qkg.510.1659372921264; Mon, 01 Aug 2022 09:55:21 -0700 (PDT) Received: from hurd (dsl-158-240.b2b2c.ca. [66.158.158.240]) by smtp.gmail.com with ESMTPSA id s5-20020a05620a254500b006b5c80e2b6asm8764046qko.12.2022.08.01.09.55.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 09:55:20 -0700 (PDT) From: Maxim Cournoyer To: Tobias Geerinckx-Rice Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> <87wnbypepu@nckx> Date: Mon, 01 Aug 2022 12:55:19 -0400 In-Reply-To: <87wnbypepu@nckx> (Tobias Geerinckx-Rice's message of "Wed, 27 Jul 2022 20:45:19 +0200") Message-ID: <87czdj3nuw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799-done Cc: attila@lendvai.name, 56799-done@debbugs.gnu.org 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, Tobias Geerinckx-Rice writes: > Hi Maxim, > > Maxim Cournoyer =E5=86=99=E9=81=93=EF=BC=9A >> For some background reading, see [0]. > > Thanks for the well-thought-out reply, and sharing this interesting > link! > > Now, it's just the musings of one person, but now I think I do agree > with (what I think is) the underlying vision: to hush up *unspecified* > and sneakily replace it with true nothingness. OK, I can live with > that. :-) > >> I think the semantic of the language is that it is to be used as the >> lack of a return value from a procedure or syntax, e.g.: >> >> (unspecified? (if #f 'one-arm-if)) -> #t > > Well=E2=80=A6 in the above context I'd hesitate to even imply > =E2=80=98semantics=E2=80=99. It's like undefined behaviour in C. Ascribe= it meaning > at your peril. Otherwise, point taken. > >> Having 'unspecified?' even defined in Guile seems to go against that >> idea; perhaps because Wingo themselves seems to disagree in [0]. > > Agreed. *This* was one of my reasons for supporting (field > *unspecified*), so it's nice to have it validated, even if it is > rejected. > >> I'm also thinking 'unspecified being too close to *unspecified* is >> probably going to cause confusion down the line. Reverting to the >> originally used 'disabled may be the lesser evil. > > Ah, here I can concentrate all my previous disagreement: hell no :-) > > It is the worstest evil; literally anything is better than > (enable-foo? 'disabled) defaulting to #t. > > Bikeshed this all y'all want, but 'default or 'unset or 'whatever are > miles better. OK. The v2 and v3 idea ended up not working, among lesser issues :-). So I went with v1, renaming the default value to 'unset; see commit a2b89a3319dc1d621c546855f578acae5baaf6da. Thanks for the naming suggestions. I also added a 'jami-provisioning-partial' system test to ensure it doesn't regress again if we decide to revisit this. Thanks, Closing. Maxim