Re: Convention for new “guix style“?

[Leo Famulari]

On Mon, Jan 03, 2022 at 09:05:00PM +0100, zimoun wrote:
> BTW, I hope you will be able to schedule some time to watch this video.
> It provides some points that appears to me being really worth to
> consider when we speak about «Grow a Community».  Rust is not a model
> to bootstrap a compiler but the community structure seems great. :-)

I definitely agree with the overall initiative of improving the Guix
community. But I'm already working, as a volunteer, at the limit of my
motivation and my ability.

Re: Convention for new “guix style“?

[zimoun]

Hi Leo,

On Mon, 03 Jan 2022 at 14:51, Leo Famulari  wrote:

>> Can you summarize Walder's law? I don't have time to watch that video.
>
> Never mind, I see that it's Wadler's law:
>
> --
> In any language design, the total time spent discussing
> a feature in this list is proportional to two raised to
> the power of its position.
>  0. Semantics
>  1. Syntax
>  2. Lexical syntax
>  3. Lexical syntax of comments
> --

The video refers to:

--8<---cut here---start->8---
The emotional intensity of debate on a language feature
increases as one moves down the following scale:
Semantics,
Syntax,
Lexical syntax,
Comments.
--8<---cut here---end--->8---



BTW, I hope you will be able to schedule some time to watch this video.
It provides some points that appears to me being really worth to
consider when we speak about «Grow a Community».  Rust is not a model
to bootstrap a compiler but the community structure seems great. :-)


Cheers,
simon

Re: Convention for new “guix style“?

[Leo Famulari]

On Mon, Jan 03, 2022 at 05:23:22PM +0100, zimoun wrote:
> Well, I disagree.  But yeah, as you said elsewhere 1) the proposal had
> been done more than 6 months ago so I had time to wake up and raise and
> 2) let avoid to fall into the Walder’s law; as exposed by the excellent
> food for thought video [1] you pointed [2].

Can you summarize Walder's law? I don't have time to watch that video.

Re: Convention for new “guix style“?

[Leo Famulari]

On Mon, Jan 03, 2022 at 02:48:27PM -0500, Leo Famulari wrote:
> On Mon, Jan 03, 2022 at 05:23:22PM +0100, zimoun wrote:
> > Well, I disagree.  But yeah, as you said elsewhere 1) the proposal had
> > been done more than 6 months ago so I had time to wake up and raise and
> > 2) let avoid to fall into the Walder’s law; as exposed by the excellent
> > food for thought video [1] you pointed [2].
> 
> Can you summarize Walder's law? I don't have time to watch that video.

Never mind, I see that it's Wadler's law:

--
In any language design, the total time spent discussing
a feature in this list is proportional to two raised to
the power of its position.
 0. Semantics
 1. Syntax
 2. Lexical syntax
 3. Lexical syntax of comments
--

Re: Convention for new “guix style“?

[zimoun]

Hi Ludo,

On Mon, 03 Jan 2022 at 16:02, Ludovic Courtès  wrote:

> When doing the first iterations of ‘guix style’¹, I found it more
> pleasant to the eye to have small lists on a single line, the prime
> example being:
>
>   (native-inputs
> (list autoconf automake libtool pkg-config))
>
> Diffs of such a list remain readable IMO.  I do agree that for longer
> lists one item per line is clearer though, which is why the pretty
> printer has this #:long-list parameter, currently defaulting to 5.
>
> There’s an opportunity to discuss style with new ‘guix style’ changes².
> However, care must be taken not to fall into the bikeshedding trap.  I
> think we must aim for readability and consistency, but also acknowledge
> that there’ll always be circumstances where one might choose a slightly
> different stylistic variant and that up to a certain level those
> variants are entirely fine.  In the end ‘guix style’ is a helper; human
> beings get the last say.

Well, I disagree.  But yeah, as you said elsewhere 1) the proposal had
been done more than 6 months ago so I had time to wake up and raise and
2) let avoid to fall into the Walder’s law; as exposed by the excellent
food for thought video [1] you pointed [2].

Cheers,
simon


1: 
2: 

Re: Convention for new “guix style“?

[Ludovic Courtès]

Hello from 2022!

I missed the bikeshedding discussion last year.  :-)

I think we can tweak style as we go, and it’s okay to have variants
around the same style IMO, but I’m against the idea of rewriting the
whole repo every time we have a new idea of what things should look
like.  This one was very much one-shot.

When doing the first iterations of ‘guix style’¹, I found it more
pleasant to the eye to have small lists on a single line, the prime
example being:

  (native-inputs
(list autoconf automake libtool pkg-config))

Diffs of such a list remain readable IMO.  I do agree that for longer
lists one item per line is clearer though, which is why the pretty
printer has this #:long-list parameter, currently defaulting to 5.

There’s an opportunity to discuss style with new ‘guix style’ changes².
However, care must be taken not to fall into the bikeshedding trap.  I
think we must aim for readability and consistency, but also acknowledge
that there’ll always be circumstances where one might choose a slightly
different stylistic variant and that up to a certain level those
variants are entirely fine.  In the end ‘guix style’ is a helper; human
beings get the last say.

Thanks,
Ludo’.

¹ https://issues.guix.gnu.org/49169
² https://issues.guix.gnu.org/52974

Re: Convention for new “guix style“?

[Ricardo Wurmus]

indieterminacy@libre.brussels writes:

> I wonder if there has been any progress made by Arun Isaac with his program, 
> Semantically meaningful S-expression diff
>
> https://archive.fosdem.org/2021/schedule/event/sexpressiondiff/

There’s also ydiff[1].  Unfortunately, it only produces an HTML file as
output, so it cannot be used as a diff program with git.

[1]: https://github.com/yinwang0/ydiff

-- 
Ricardo

Re: Convention for new “guix style“?

[zimoun]

Hi,

On Wed, 22 Dec 2021 at 22:18, Liliana Marie Prikler
 wrote:
> Am Mittwoch, dem 22.12.2021 um 14:05 +0100 schrieb zimoun:

> > --8<---cut here---start->8---
> >  `(("libx11" ,libx11)
> >("libiberty" ,libiberty)   ;needed for objdump
> >("zlib" ,zlib)))   ;also needed for objdump 
> > support
> > --8<---cut here---end--->8---
> >
> > Other said, this looks better:
> >
> > --8<---cut here---start->8---
> > (inputs
> >  (list libx11
> >libiberty ;needed for objdump support
> >zlib));also needed for objdump support
> > --8<---cut here---end--->8---

[...]

> For me personally, this illustrates two things.  First, the weakness of
> line comments over preceding line comments ad second the verbosity of
> old input style.  You could easily write
>
>   (list libiberty zlib) ; for objdump

What about 'libx11'?   Otherwise, you end with cons (append for some
cases) or something along these lines,

(inputs
  (cons
 libx11
 (list libiberty zlib))) ;for objdump

I am not convinced it is better...

> in the new style, which you couldn't before.  Therefore, I wouldn't

Yes, I could do it in the old style:

  `(("libx11" ,libx11)
("libiberty" ,libiberty) ("zlib" ,zlib)))  ;for objdump support

I have never read such thing.  And I miss your point because from my
understanding, it is not related to old style (list using labels)
versus new style (just list).

> mandate a "one line per input" restriction, as the only reason it was
> ever imposed was a historical limitation.

I miss your comment here.  It is possible to write

(inputs `(("foo" ,bar) ("baz" ,done)))

and I have not done stats but I guess the rule for old style is: one
item per line whatever the numbers, comments or length.  Because, I
guess again, readibility matters. :-)


> > This would avoid “cosmetic” changes when adding/removing inputs
> > and/or comments.
>
> In my personal opinion, everything else being equal, changes to
> inputs/native-inputs/propagated-inputs should (almost) always be seen
> as changes to the field, as would be documented in the ChangeLog.
>
> I think the usual scheme coding guidelines also apply well to inputs,
> e.g. inline short stuff, but don't do funky things when the lines grow
> unnecessarily long.

If that argument holds, then why is it not applied for old style? ;-)

We do not read,

--8<---cut here---start->8---
(native-inputs
 `(("pkg-config" ,pkg-config) ("python" ,python-wrapper)))
--8<---cut here---end--->8---

for gnu/packages/video.scm (mediasdk) as example.


Cheers,
simon

Re: Convention for new “guix style“?

[indieterminacy]

I wonder if there has been any progress made by Arun Isaac with his program, 
Semantically meaningful S-expression diff

https://archive.fosdem.org/2021/schedule/event/sexpressiondiff/

```
Traditional diff implementations, such as GNU Diff, treat files as a
flat list of lines. A tree-diff algorithm that can produce minimal and
semantically meaningful output is a surprisingly more difficult and
complex problem. In fact, for unordered trees, the problem is NP-hard.
```


Jonathan

Liliana Marie Prikler  writes:

> Hi,
>
> Am Mittwoch, dem 22.12.2021 um 14:05 +0100 schrieb zimoun:
>> [...]
>> --8<---cut here---start->8---
>>     (inputs
>>  (list libx11 libiberty ;needed for objdump support
>>    zlib))   ;also needed for objdump
>> support
>> --8<---cut here---end--->8---
>> 
>> when the comments apply to only one line as it was:
>> 
>> --8<---cut here---start->8---
>>  `(("libx11" ,libx11)
>>    ("libiberty" ,libiberty)   ;needed for objdump
>> support
>>    ("zlib" ,zlib)))   ;also needed for
>> objdump support
>> --8<---cut here---end--->8---
>> 
>> Other said, this looks better:
>> 
>> --8<---cut here---start->8---
>>     (inputs
>>  (list libx11
>>    libiberty ;needed for objdump support
>>    zlib))    ;also needed for objdump support
>> --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.
> For me personally, this illustrates two things.  First, the weakness of
> line comments over preceding line comments ad second the verbosity of
> old input style.  You could easily write 
>   (list libiberty zlib) ; for objdump
> in the new style, which you couldn't before.  Therefore, I wouldn't
> mandate a "one line per input" restriction, as the only reason it was
> ever imposed was a historical limitation.
>
>> Consider the case,
>> 
>>     (inputs
>>  (list bar foo1 foo2 foo3 foo3 foo4))
>> 
>> then another ’baz’ 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))
>> 
>> ?  And the converse is also true, consider the case just above and
>> what
>> happens if foo1, foo2 and foo3 are removed.
>> 
>> One item per line solves all these boring cosmetic questions.
>> 
>> Therefore, I propose to always have only one item per line.  To be
>> concrete, for one item:
>> 
>>   (inputs
>>    (list foo))
>> 
>> or not
>> 
>>   (inputs (list foo))
>> 
>> And for more than one item:
>> 
>>   (inputs
>>    (list foo
>>  bar))
>> 
>> This would avoid “cosmetic” changes when adding/removing inputs
>> and/or comments.
> In my personal opinion, everything else being equal, changes to
> inputs/native-inputs/propagated-inputs should (almost) always be seen
> as changes to the field, as would be documented in the ChangeLog.
>
> I think the usual scheme coding guidelines also apply well to inputs,
> e.g. inline short stuff, but don't do funky things when the lines grow
> unnecessarily long.
>
> Now I am putting aside the issue of tooling here, because I think that
> humans ought to be able to look at the diff and see that something's
> wrong and correct it, but as others point out an "I don't touch
> comments" approach would be very fine by me.
>
> Cheers

Re: Convention for new “guix style“?

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 22.12.2021 um 14:05 +0100 schrieb zimoun:
> [...]
> --8<---cut here---start->8---
>     (inputs
>  (list libx11 libiberty ;needed for objdump support
>    zlib))   ;also needed for objdump
> support
> --8<---cut here---end--->8---
> 
> when the comments apply to only one line as it was:
> 
> --8<---cut here---start->8---
>  `(("libx11" ,libx11)
>    ("libiberty" ,libiberty)   ;needed for objdump
> support
>    ("zlib" ,zlib)))   ;also needed for
> objdump support
> --8<---cut here---end--->8---
> 
> Other said, this looks better:
> 
> --8<---cut here---start->8---
>     (inputs
>  (list libx11
>    libiberty ;needed for objdump support
>    zlib))    ;also needed for objdump support
> --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.
For me personally, this illustrates two things.  First, the weakness of
line comments over preceding line comments ad second the verbosity of
old input style.  You could easily write 
  (list libiberty zlib) ; for objdump
in the new style, which you couldn't before.  Therefore, I wouldn't
mandate a "one line per input" restriction, as the only reason it was
ever imposed was a historical limitation.

> Consider the case,
> 
>     (inputs
>  (list bar foo1 foo2 foo3 foo3 foo4))
> 
> then another ’baz’ 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))
> 
> ?  And the converse is also true, consider the case just above and
> what
> happens if foo1, foo2 and foo3 are removed.
> 
> One item per line solves all these boring cosmetic questions.
> 
> Therefore, I propose to always have only one item per line.  To be
> concrete, for one item:
> 
>   (inputs
>    (list foo))
> 
> or not
> 
>   (inputs (list foo))
> 
> And for more than one item:
> 
>   (inputs
>    (list foo
>  bar))
> 
> This would avoid “cosmetic” changes when adding/removing inputs
> and/or comments.
In my personal opinion, everything else being equal, changes to
inputs/native-inputs/propagated-inputs should (almost) always be seen
as changes to the field, as would be documented in the ChangeLog.

I think the usual scheme coding guidelines also apply well to inputs,
e.g. inline short stuff, but don't do funky things when the lines grow
unnecessarily long.

Now I am putting aside the issue of tooling here, because I think that
humans ought to be able to look at the diff and see that something's
wrong and correct it, but as others point out an "I don't touch
comments" approach would be very fine by me.

Cheers

Re: Convention for new “guix style“?

[André A . Gomes]

zimoun  writes:

> And “guix style” is a step toward fixing Danny’s 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.
>
> 

I agree and disagree.

(Disagree).  Lisps hardly ever need external formaters or linters since
you basically write down an AST.  The "linting" job is done by the
editor itself (think C-M-q and electrical indentation in major modes).
Yes, there is ambiguity in some cases, but the decision is (rightly)
left to the programmer.  I believe that it's precisely the lack of
"structure" in other languages that motivates the need for such tooling.

(Agree).  If we turn to the concrete issue at hand, cosmetic and "diff"
issues of Guix packages, then I agree that this would (ideally) be a
task for a tool (guix lint).  Because it's important to have consistency
and we can agree on the standards.  I'm arguing that in this case the
ambiguity (mentioned above) vanishes, and so the style can be enforced.

When I go shopping, I write the list down in same way you do, Zimoun :)


-- 
André A. Gomes
"Free Thought, Free World"

Re: Convention for new “guix style“?

[Andreas Enge]

Am Wed, Dec 22, 2021 at 09:23:33AM -0800 schrieb Vagrant Cascadian:
> It might be a big change, but probably wouldn't trigger rebuilds ... ?

No, it would only change the source code; I am all for it!

Andreas

Re: Convention for new “guix style“?

[Vagrant Cascadian]

On 2021-12-22, zimoun wrote:
> We had a discussion on IRC starting here [2].  This proposal is to
> document in the manual and adapt ‘guix style’ to have one input per line
> – as it was the case with the old style.

Yes, please! One input per line is simpler to understand, simpler to
implement, and makes for much easier to read diffs, all for the
relatively low cost of a few newlines. :)


> Sadly, it implies another Big Change.  But earlier is better and we
> should do it as soon as possible while the conversion is not totally
> done yet.

It might be a big change, but probably wouldn't trigger rebuilds ... ?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Convention for new “guix style“?

[zimoun]

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 “exception” for this case.

(inputs
 (list foo bar
   baz   ;for tests
   bang boum))

The tool already contains an “exception” for this other case.

--8<---cut here---start->8---
(inputs
 (list julia-chainrulestestutils julia-finitedifferences julia-nanmath
   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 ’baz’ 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. 

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.

«Automatically apply it» is not straightforward.  We already have a
great tool “guix lint” 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 “guix style” is a step toward fixing
Danny’s 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 “cosmetic” 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 <= 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: «Don't put multiple inputs on a single line
unless you have something to hide». ;-)

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 

Re: Convention for new “guix style“?

[Jelle Licht]

Hi,

zimoun  writes:

> Hi,
>
> This could be part of a RFC process. :-)
>
>
> The Big Change introduces new style, other said, this old
>
> --8<---cut here---start->8---
>  (native-inputs
>  `(("perl" ,perl)
>("pkg-config" ,pkg-config)))
> --8<---cut here---end--->8---
>
> is replaced by this new,
>
> --8<---cut here---start->8---
>  (native-inputs
>   (list perl pkg-config))
> --8<---cut here---end--->8---
>
> It removes all the labels. \o/  More details [1].
>
>
> We had a discussion on IRC starting here [2].  This proposal is to
> document in the manual and adapt ‘guix style’ to have one input per line
> – as it was the case with the old style.
>
> Aside preference, for instance, I find easier to read,
>
> --8<---cut here---start->8---
> (inputs ;required for test
>  (list julia-chainrulestestutils
>julia-finitedifferences
>julia-nanmath
>julia-specialfunctions))
> (propagated-inputs
>  (list julia-chainrulescore
>julia-compat
>julia-reexport
>julia-requires))
> --8<---cut here---end--->8---
>
> than
>
> --8<---cut here---start->8---
> (inputs ;required for test
>  (list julia-chainrulestestutils julia-finitedifferences julia-nanmath
>julia-specialfunctions))
> (propagated-inputs
>  (list julia-chainrulescore julia-compat julia-reexport
>julia-requires))
> --8<---cut here---end--->8---
>
> but this is somehow bikeshed.  However, the current situation leads to
> non-uniform or ambiguity.
>
> For example, the comments as here:
>
> --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!

> when the comments apply to only one line as it was:
>
> --8<---cut here---start->8---
>  `(("libx11" ,libx11)
>("libiberty" ,libiberty)   ;needed for objdump support
>("zlib" ,zlib)))   ;also needed for objdump support
> --8<---cut here---end--->8---
>
> Other said, this looks better:
>
> --8<---cut here---start->8---
> (inputs
>  (list libx11
>libiberty ;needed for objdump support
>zlib));also needed for objdump support
> --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.

> Consider the case,
>
> (inputs
>  (list bar foo1 foo2 foo3 foo3 foo4))
>
> then another ’baz’ 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.

> 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. 

> Therefore, I propose to always have only one item per line.  To be
> concrete, for one item:
>
>   (inputs
>(list foo))
>
> or not
>
>   (inputs (list foo))
>
> And for more than one item:
>
>   (inputs
>(list foo
>  bar))
>
> This would avoid “cosmetic” 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 <= 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 :-).

> Sadly, it implies another Big Change.  But earlier is better and we
> should do it as soon as possible while the conversion is not totally
> done yet.

I agree, so here's a 

Convention for new “guix style“?

[zimoun]

Hi,

This could be part of a RFC process. :-)


The Big Change introduces new style, other said, this old

--8<---cut here---start->8---
 (native-inputs
 `(("perl" ,perl)
   ("pkg-config" ,pkg-config)))
--8<---cut here---end--->8---

is replaced by this new,

--8<---cut here---start->8---
 (native-inputs
  (list perl pkg-config))
--8<---cut here---end--->8---

It removes all the labels. \o/  More details [1].


We had a discussion on IRC starting here [2].  This proposal is to
document in the manual and adapt ‘guix style’ to have one input per line
– as it was the case with the old style.

Aside preference, for instance, I find easier to read,

--8<---cut here---start->8---
(inputs ;required for test
 (list julia-chainrulestestutils
   julia-finitedifferences
   julia-nanmath
   julia-specialfunctions))
(propagated-inputs
 (list julia-chainrulescore
   julia-compat
   julia-reexport
   julia-requires))
--8<---cut here---end--->8---

than

--8<---cut here---start->8---
(inputs ;required for test
 (list julia-chainrulestestutils julia-finitedifferences julia-nanmath
   julia-specialfunctions))
(propagated-inputs
 (list julia-chainrulescore julia-compat julia-reexport
   julia-requires))
--8<---cut here---end--->8---

but this is somehow bikeshed.  However, the current situation leads to
non-uniform or ambiguity.

For example, the comments as here:

--8<---cut here---start->8---
(inputs
 (list libx11 libiberty ;needed for objdump support
   zlib))   ;also needed for objdump support
--8<---cut here---end--->8---

when the comments apply to only one line as it was:

--8<---cut here---start->8---
 `(("libx11" ,libx11)
   ("libiberty" ,libiberty)   ;needed for objdump support
   ("zlib" ,zlib)))   ;also needed for objdump support
--8<---cut here---end--->8---

Other said, this looks better:

--8<---cut here---start->8---
(inputs
 (list libx11
   libiberty ;needed for objdump support
   zlib));also needed for objdump support
--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.


Consider the case,

(inputs
 (list bar foo1 foo2 foo3 foo3 foo4))

then another ’baz’ 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))

?  And the converse is also true, consider the case just above and what
happens if foo1, foo2 and foo3 are removed.

One item per line solves all these boring cosmetic questions.

Therefore, I propose to always have only one item per line.  To be
concrete, for one item:

  (inputs
   (list foo))

or not

  (inputs (list foo))

And for more than one item:

  (inputs
   (list foo
 bar))

This would avoid “cosmetic” changes when adding/removing inputs and/or
comments.

Sadly, it implies another Big Change.  But earlier is better and we
should do it as soon as possible while the conversion is not totally
done yet.

Cheers,
simon

1: 
2: