Hi Ryan! >> I can tell you that those cosmetic changes I made were 100% irrational, >> useless and noisy. > > That's certainly a way to frame it, but I'd like to hold some space for the > idea that the things we > neuroatypical people do to manage and satisfy our own unusual perspectives > are not irrational or > useless if they make sense to us and serve a purpose for us.
+1 I meant to say that, the actions were irrational by itself. But when contrasted with right reasons, we can see why sometimes an irrational act can be a rational act, when it benefits the agent's overall outcome. >> Due to [clinical conditions], if the packages I am editing is not it in a >> specific way, I am unable >> to focus properly. That too, if I am working on multiple package definitions >> and if each pack-defs >> are arranged in different way, it is very very hard for me. > > That is an interesting use-case I hadn't considered, but a valid one, and it > gives me ideas. I'm > going to experiment with some tools to make this feasible. Thanks Ryan! Yeah, my brain laterally connects fields of different package definitions. Like a spread-sheet, where each columns are different package definitions and each row is a fields of a package's definition. For example, if column 1 is glib and column 2 is gtk+, my brain spots pattern or errors when [arguments] field of both the packages are in the same row. Let's say [arguments] field of glib pack-def (column) is in 4th place (row); and; if the 4th place (row) of gtk+ pack-def (column) is [propagated-inputs]; my brain goes haywire. So I first do the cosmetic change of rearranging the fields of gtk+ pack-def to match with pack-def of gtk+. This is just one example. > Consider the tooling for Unison[1] which reduces code churn in a number of > unique ways.[2] It can > store programs as abstract syntax trees rather than plain text files, and > it's content-addressed, > referring to functions by their hashes rather than their fixed names. As a > programmer that gives > you the freedom to choose names and language syntax that suit you without > imposing on others to > follow suit. That's very interesting. I'll have a look. > Due to the functional paradigm and technical structure of Guix, I think we > can build some of the > same capabilities in our tooling. Like Unison functions, our package > definitions are reduced to a > declarative content-addressed form, from which a textual definition could be > generated again using > a reverse process. By such a process, you & I could edit package definitions > in whatever textual > form suits us individually without having to agree on anything, not even the > names of symbols. Then > we can use a tool to automatically canonicalize our code into the form most > widely acceptable to > the community when it's time to submit a patch. +1 > Taking this idea to its logical conclusion & building on Guile's > multi-language-syntax paradigm, I > can picture using a futuristic tool to edit package definitions in Emacs lisp > or JavaScript, again > without requiring that anybody upstream adopt those languages or even > recognize that I'm using > them. > > I'll see what I can hack together for a naïve implementation of this concept > and present it for > review. Thank you Ryan! >> Moving forward, I will try hard not to do this. But can I ask you all to >> allow these cosmetic >> commits for my existing projects (i.e. commits from wip-desktop and pidgin >> patch-set) please? > > It doesn't bug me, but I know it does bug other people and imagine we want to > avoid creating > unnecessary review work for people who follow the commit stream. I see. >> I understand that these commits were a burden to everyone and my sincere >> apologies for that. > > I appreciate the grace and consideration you brought to your response & all > your contributions to > Guix! :-) > [1] https://www.unisonweb.org > [2] > https://www.unisonweb.org/2020/04/10/reducing-churn/#definitions-getting-renamed-or-moved Regards, RG.
