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 <[email protected]> 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
