Re: Convention for new “guix style“?

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Wed, 22 Dec 2021 at 22:18, Liliana Marie Prikler
<liliana.prikler@gmail.com> 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