From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id qBq6Ht/gKmS9FQEASxT56A (envelope-from ) for ; Mon, 03 Apr 2023 16:21:19 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UMuYHt/gKmT7vwAA9RJhRA (envelope-from ) for ; Mon, 03 Apr 2023 16:21:19 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2E1A9F765 for ; Mon, 3 Apr 2023 16:21:19 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjL3I-0002AA-6R; Mon, 03 Apr 2023 10:20:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pjL3H-0002A2-8C for guix-devel@gnu.org; Mon, 03 Apr 2023 10:20:55 -0400 Received: from smtpm5.myservices.hosting ([185.26.105.236]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pjL3F-0004fe-JM for guix-devel@gnu.org; Mon, 03 Apr 2023 10:20:54 -0400 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpm5.myservices.hosting (Postfix) with ESMTP id 3FBE120CBE; Mon, 3 Apr 2023 16:20:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id 5F1B0800B3; Mon, 3 Apr 2023 16:13:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail1.netim.hosting Received: from mail1.netim.hosting ([127.0.0.1]) by localhost (mail1-2.netim.hosting [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id e3Iu9vk5KIcT; Mon, 3 Apr 2023 16:13:03 +0200 (CEST) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id D4003800AD; Mon, 3 Apr 2023 16:13:02 +0200 (CEST) Message-ID: <66232cd3-ff0b-e248-1ae0-4839e793e994@makinata.eu> Date: Mon, 3 Apr 2023 15:13:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [RFC] Cosmetic changes to define-configuration usage Content-Language: en-US To: Maxim Cournoyer Cc: guix-devel , cox.katherine.e@gmail.com References: <87lejdvuzn.fsf@gmail.com> From: Bruno Victal In-Reply-To: <87lejdvuzn.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=185.26.105.236; envelope-from=mirai@makinata.eu; helo=smtpm5.myservices.hosting X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-1.349, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1680531679; a=rsa-sha256; cv=none; b=glONQAyekcPiDV8a927NlE61XuzrtW5wDyyZMltC2T61KXeaYvb34hQ1pd56qAA1IOnOqo 2d3W9o3hMFaqgX2zAzleg8Tk1JJfN3SipkI/E242vGnVswYIAJ9n1D56RiQfRAsBJmSc/J 5UGpRTIrE6XmbLQp7NEgv0xmoOl/6KP4hEmi/uh5Jd18m4fpo0pReqZMV/9MVmdGBq23wx 2h2PuACKJzlpAkoI43INgn9QG7vvJ73J6P/Ti8WWhVK1FrE/Uc6N1+23EafBRvOyKEkxZS BibfxeLQEYCcyPuUpw6Yn1D8dYFvtuBHjvwkentlHm/qIs2bgodAaQJRm8KEdw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1680531679; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=EqfX3ONVdmBf+GOusPpTsU+adH8GXvRqEM7BIyoghqk=; b=oIOhQxlhRoWLm6Kuudf8EffYV/SZfDO0ScVlzUpcjQIXHSUfqAON8AKJhtcYZrR2EroUI2 nmCYqi+iiemEk44IIDtMe+KwB7z6LStSdJlsbZFrMQVX00NzlKxULa3XhWbPWQaqzt3DdY p6lNfna+UGnMie/aZkKJrM+aZPLfSwSrJ8ultbH4mBgL1mfLrNcCg3iblGz7HRgmlhjuf3 3AtsoxzDrGxKRsEkzuetcq6M+8Km4YusoO9P0L14ZhssREMD2cccsycI2kdbdkS4OgQPJ2 fq6EE/6V8Itqhe0pyPeY5toRJ54JNfTap08R9jDOhwvlN2LweTig3omFWoatTg== X-Migadu-Spam-Score: -3.02 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Spam-Score: -3.02 X-Migadu-Queue-Id: 2E1A9F765 X-TUID: DMDo6Xs3Ha7C On 2023-03-31 15:46, Maxim Cournoyer wrote:> I have some apprehension that if we start adding white space between the > fields here, we'll soon have people adding white space to many other > places (for consistency or other reasons), which I wouldn't welcome (I > value compactness, and since in Scheme a single newline is used to > delimit things at the top level, too much of white space can make things > less readable in my opinion). I don't think it needs to be an all-or-nothing situation, the spacing rules can be always applied selectively “when it makes sense”. I think spaces between fields is consistent with the general way of things, for instance, throughout Guix, sections that are only scheme code often do have some spaces here and there that were added without any adherence to some rigid criteria but the programmer found it to be an adequate point to partition the logic. The same reasoning applies here, the logic partitioning is done per field instead. Objectively, there's also a small quantitative difference that's not commonly present in the rest of the codebase. define-configuration handles both code and documentation, or putting it another way, it intersperses code and (rather long) strings. The result is that it's particularly information-dense compared to any other part of the guix codebase. My 2¢! Cheers, Bruno