From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id kG1iJ7dKw2GAFwEAgWs5BA (envelope-from ) for ; Wed, 22 Dec 2021 16:56:39 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id COckI7dKw2HCAgAAB5/wlQ (envelope-from ) for ; Wed, 22 Dec 2021 15:56:39 +0000 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 45C27261 for ; Wed, 22 Dec 2021 16:56:39 +0100 (CET) Received: from localhost ([::1]:35094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n03yo-0001GY-9u for larch@yhetil.org; Wed, 22 Dec 2021 10:56:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n03yM-0001Ek-0y for guix-devel@gnu.org; Wed, 22 Dec 2021 10:56:10 -0500 Received: from [2a00:1450:4864:20::432] (port=44954 helo=mail-wr1-x432.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n03yH-0007xy-1a for guix-devel@gnu.org; Wed, 22 Dec 2021 10:56:08 -0500 Received: by mail-wr1-x432.google.com with SMTP id t18so5766638wrg.11 for ; Wed, 22 Dec 2021 07:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:in-reply-to:references:date:message-id:mime-version :content-transfer-encoding; bh=Wff6ialna47MDUtwkTBQW3xopEUgbwZcMT3BqHLEaxM=; b=EHz8L7dI00PU8U3kGUyVt8qc7DqAMKcNpOQrTRa0R6geEgMaNBGzG4AN3yDofT5tQe IQZEkwLJ8Hl/1nx+p7LFHOBuljtpySyygBsMlwQ5WMazzRGZhv1R65RO7+5c2fyBOYVt TkgfDNs5DW6kzJ2AhMVdxTkaCV7U2W2I1XmLwh38pS1kttOwQTdYHxDQFP8KN86diFhM S8CIgFXUcllDGvjf4iaEmdoWniKYKIDTFAf40M39Iu0y1ibVxl9ykte9bVifrsHHNnVT HHGQbfiaUcKIRQEpYdAn21TFCEofGxp/9ATS/9g18Yung+eTRm23ab+PzYkyqge7Gac8 +52A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=Wff6ialna47MDUtwkTBQW3xopEUgbwZcMT3BqHLEaxM=; b=g8vwD75QJvHf0TmZUDfibgU/tzWm1/Wmf24kAtnCEBEHcZmRxRh5JgJnpfNSMYMvSR R8CMIbh/rGmDgYcQf16PO3Ys39rmSJqLTPCby+vwhnCtfHOfCv7kChDnzwjx2TKffbay CramUDKd/2Dh5vZt13DPoZ8iRub+VfKKRv9p1mHr62uSp0olTwDLuD/GuEXQHSYCZP56 8KGANibmHeGw/NeK+Hpbk47L5W+md/WolphRcQRYmVK3SMhECSJ7PUz6oPG5pRe3Ki03 3GZW8CL+TH83tdy1nOjf2iZ3kHa+wTXXIx6pjCgs/wEboTkz6FrJ4c34tfim3nKu3CYI EsuQ== X-Gm-Message-State: AOAM531Hx6RbU3Pa+bis5F2UhoNxAd05dyNPpj7/rcTTOhp1Vxq/8eaX g7Qdjk3Y+JJN9yaVG4+pC3/y6eULHSY= X-Google-Smtp-Source: ABdhPJyVdbpsU4xYhJdPmX6Pn49C8Ub+Mpe06ch7+7ZEkbyjwRggXumuceA4OWqYbEps18tU1rxxfA== X-Received: by 2002:a5d:6481:: with SMTP id o1mr2529176wri.570.1640188563487; Wed, 22 Dec 2021 07:56:03 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id d62sm5604382wmd.3.2021.12.22.07.56.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 07:56:03 -0800 (PST) From: zimoun To: Jelle Licht , Guix Devel Subject: Re: Convention for new =?utf-8?Q?=E2=80=9Cguix_style=E2=80=9C=3F?= In-Reply-To: <86a6gsd91p.fsf@fsfe.org> References: <86bl18sscd.fsf@gmail.com> <86a6gsd91p.fsf@fsfe.org> Date: Wed, 22 Dec 2021 16:52:33 +0100 Message-ID: <86y24cr60u.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::432 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::432; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x432.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1640188599; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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:dkim-signature; bh=Wff6ialna47MDUtwkTBQW3xopEUgbwZcMT3BqHLEaxM=; b=i76aZNoBPqKYGwDUv9xFXfQCu2UWPO4xS2N0TV0XxUxohu/1Hhlzy4GUlG2Ia/q4VuTsTZ cTTZUpZmXiGZtWcPcnyj3KN0IjhDuSOWOIOzTFQ4XXlTgb6nQKtQ8lezJu8+U0URmgOoIj yPBVZs7anCm65jqqaNjmuBPMd5+eGVeLsdZ76nJcTMeEcf7vMej3LNVB6ImlLcuYYG3dHO ic0AiOMxvWhStP7xwFholRLNIPftXp8Shx8pbcC8cuicGa3I0CH2HdzQSiJAFXSfn4fWxl CoVMXiPeCo7hsZa2wu9XzaId1oO/9NJ1cgQEh669yDPd9NOmroMS6xffQDHjZg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640188599; a=rsa-sha256; cv=none; b=EeJq19ZySkaZWvcGBeJ7z/kD3Tat5FbtaUNi/xHoYjYQg2gxvrHO+w6IBnZyul9VAa/7vj Wj4gy6wy1wzGFUDmQRy/iuqpBZIe2OgvQKKZtz1hDtBEtZHplW0vjRmYw27BqOdcbNpb3Y U4ffzoJbCjismH7BlbY4hq+uOVX/nTcjKKwwU/CWMq5wmSyJGoB3RPeM/1h57deWL3z+EK VC52CW/KEDdLsHe6lotwBx5VTnudH6sB1k+jhazzWH9YbHlwNYmlUxUCBYMKLbSWtKhV40 cDDYUvYytHsAEdhxfCf/BhKUmqL2YEsAUZD02ZNlrR0+ZSOzW4ctpCGsDa+Crw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=EHz8L7dI; dmarc=pass (policy=none) header.from=gmail.com; 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-Migadu-Spam-Score: -4.74 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=EHz8L7dI; dmarc=pass (policy=none) header.from=gmail.com; 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-Migadu-Queue-Id: 45C27261 X-Spam-Score: -4.74 X-Migadu-Scanner: scn0.migadu.com X-TUID: iq+w4cNJF7jX Hi Jelle, We are consistent with what we already said on IRC. ;-) On Wed, 22 Dec 2021 at 15:10, Jelle Licht wrote: >> --8<---------------cut here---------------start------------->8--- >> (inputs >> (list libx11 libiberty ;needed for objdump support >> zlib)) ;also needed for objdump support >> --8<---------------cut here---------------end--------------->8--- > > Yuck indeed! Therefore, the tool requires a first =E2=80=9Cexception=E2=80=9D for this c= ase. (inputs (list foo bar baz ;for tests bang boum)) The tool already contains an =E2=80=9Cexception=E2=80=9D for this other cas= e. --8<---------------cut here---------------start------------->8--- (inputs (list julia-chainrulestestutils julia-finitedifferences julia-nanm= ath julia-specialfunctions)) --8<---------------cut here---------------end--------------->8--- >> Obviously, we could come up a rule depending on comments, numbers of >> inputs, length, etc. It was not the case with the old style when >> nothing prevented us to do it. Because one item per line is, IMHO, >> easier to maintain. > > You seem to be putting the cart before the horse here; we should not let > our (lack of) tooling determine our styling preferences. Hum, I do not know. Maybe. For sure, I write my grocery list as: + apple + orange + beer + flour and not, apple orange beer flour but all the flavours are equal. :-) >> Consider the case, >> >> (inputs >> (list bar foo1 foo2 foo3 foo3 foo4)) >> >> then another =E2=80=99baz=E2=80=99 inputs is added, do we end with, >> >> (inputs >> (list bar foo1 foo2 foo3 foo3 foo4 >> baz)) >> >> to minimize and ease reading the diff, or do we end with, >> >> (inputs >> (list bar >> baz >> foo1 >> foo2 >> foo3 >> foo3 >> foo4)) > > The second, ideally. > >> ? And the converse is also true, consider the case just above and what >> happens if foo1, foo2 and foo3 are removed. > > Everything gets put on a single line again. This makes the diffs harder to deal with. Because one part of the issue is about comparing revision A with revision B, not just the read the list at one specific revisin. Going back and forth to multi and single line is error-prone, IMHO. I agree that 1. comparing does not happen so frequently but still, and 2. it does not happen to so many packages but still. For sure, S-Diff presented by Arun [1] at last FOSDEM 2021 would help. AFAIK, this kind of tool is not ready for day-to-day usage and not yet integrated with Git. 1: >> One item per line solves all these boring cosmetic questions. > > To be fair, any policy that can be automatically applied solves those > very same boring cosmetic questions. I agree that whatever style we end > up with, we should be able to automatically apply it.=20 I agree that tools can help. However, at some point, we effectively read and the default policy should ease this reading, even with plain text without any tools. =C2=ABAutomatically apply it=C2=BB is not straightforward. We already have= a great tool =E2=80=9Cguix lint=E2=80=9D and it is not automatically applied. For sure, I also think that automatic tools is the direction to go, for sure I want more automation. And =E2=80=9Cguix style=E2=80=9D is a step to= ward fixing Danny=E2=80=99s words: FWIW, I do find it strange that Lisp projects, despite using a minimal-syntax language (mostly in order to conserve its regular tree structure), do not usually automatically format source code as they check in, but Go projects, using the prime example of an irregular C-like language, DOES usually use code formatters automatically when checking in. That is some strange reversal of strengths that I wouldn't have expected. >> This would avoid =E2=80=9Ccosmetic=E2=80=9D changes when adding/removing= inputs and/or >> comments. > > This is not a convincing argument to me; I very much doubt that we have > that many packages that switch back and forth between having <=3D 4 and > > 4 inputs constantly. That is not to say that I think we won't see it > happen; I just don't think it happens often enough to warrant what you > are proposing :-). As I am pointing, comment is an issue, obscure diff is another, 4 long-names which splits into 2 lines is another. These 3 cases are just things that annoyed me reviewing OCaml update and packaging Julia, after one week or so using this new style. (Issue is a strong word for this bikeshed. ;-)) As a good coding style says: =C2=ABDon't put multiple inputs on a single li= ne unless you have something to hide=C2=BB. ;-) However, I do not see the advantages for one line. :-) > I agree, so here's a counter-proposal: adjust the convention and guix > style to leave inputs-with-comments alone. Only put inputs on one line > when there are fewer than N items (configurable, but for now 5), as well > as no comments on any of the lines. You are proposing to implement more =E2=80=9Crules=E2=80=9C. :-) Why not, b= ut it appears to me a French mindset ;-) add more cases and layers instead of just simplify with one unique as simple as possible rule. Cheers, simon