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 <liliana.prikler@gmail.com> 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