Hi Maxime,

I have to be perfectly up-front: past interactions like this, which appear
to me as more or less a means to gatekeep the contribution process by tying
up others' time in disagreement over what is ultimately minutiae (I'll get
into specifics momentarily), ultimately drove me away from contributing to
and interacting with Guile & Guix in any capacity for the past 6 months,
and others in the community have shared similar frustrations that have
caused them to become detached from the project as well.

If we look at the last time I posted to the list 6 months ago, I was hoping
to offer some simple contributions: proof reading edits for additions to
the docs, which I was actively working on at the time:
https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00087.html

In your responses to me, both then an now, its as if the actual content of
my corrections were ignored. No time was taken to consider my rationale, or
even the literal meaning of words I employed. You appear to me to be
motivated more by the desire to argue rather than to collaborate on
improving Guix to the best of our abilities. You even mention in your first
reply that the sequence of examples is "presumably" better, implying you
didn't take the time to even work through the interlocking contents,
preferring rather to shoot down the contribution.

But im surely just being cranky over a one off minor dispute from 6 months
ago, right? Let's look back at my previous posting to guix-devel before
that, when I was considering creating a wiki that can be edited from the
browser that could actually as a sort of "documentation staging" area. The
first response? Maxime in disbelief that anyone would ever want to waste
their time creating a wiki:
https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00391.html

And there's more, its a pattern; I dont know if you troll everyone like
this or if I represent something you feel opposed to, but I do know that it
was enough for me to become allergic to Guile/Guix community until I
started hanging out on Mastodon and discovered many guix have retreated
there.

Now let's get into the specifics of the current patch review where I'll
show why I think your efforts aren't in earnest, and even appear malign:

On Sun, Jan 29, 2023 at 3:30 PM Maxime Devos <maximedevos@telenet.be> wrote:

>
>
> On 29-01-2023 04:04, Blake Shaw wrote:
> >
> >
> >
> >     On 26-01-2023 19:57, Blake Shaw wrote:
> >      >   @example
> >      > -(match lst
> >      > -  (((heads tails ...) ...)
> >      > -   heads))
> >      > +(match '(((a b c) e f g) 1 2 3)
> >      > +  (((head ...) tails ...)
> >      > +   `(,@tails ,head)))
> >      > +@result{} (1 2 3 ((a b c) e f g))
> >      >   @end example
> >
> >
> >      >>Contrary to the commit message, this >>isn't an addition of a
> >     pattern
> >      >>matching example, it's a change.
> >      >>Aside from inlining 'lst', what's this >>change for?
> >
> >
> > The offered example cant be executed. Its up to the reader to figure
> > out, which isn't valuable to anyone trying to understand the matcher in
> > first place. Again, ee the linked presentation for much on these matters
> > and more.
>

There's a lot going on in what follows so let's take a look.

>
> The offered example indeed can't be executed.  However, inlining 'lst'
> is sufficient to make it execute (*), and I asked for ‘**aside from
> inlining** 'lst', what's this change for?’ (emphasis added)


1. You first admit that the original example cant execute. We agreed on
guix days that examples should work without users having to put the pieces
together themselves. Its therefore obvious that a change is required,
whether or not you said **aside from inlining**. The old examples were
agreed to be poor and insufficient. My contribution is meant to improve
them, and I think if we got the Guix community to look at the before and
after, the *overwhelming majority* would agree the final result improves
the pattern matching section by leaps and bounds.

2. You claim that it would be sufficient to "inline" lst. Even if this were
correct, which it isn't because `@,any-bound-identifier is an incorrect
application of quasiquotation excepting defmacro (quasiquoting the
unquote-splicing of a bound identifier va always results in a list of the
form (unquote-splicing var) because at that point you merely quoted the
datum unquote-splicing. unquote-splicing has to splice at a nonterminal
location of an ordered form like lists or arrays and thus performs the same
function as periods that aren't in dotted tail position)... what is the
pedogagogical value of showing that? If it did work as you expect, what
would it impart on the reader? Nothing except perhaps that unquote-splicing
exists, while my example actually demonstrates important, subtle properties
of match that would apparently be valuable for you to take the time to
actually read and comprehend, which is part of your duty as a reviewer in
the first place.


> (*) E.g. take lst = '((x) (y y0) (z z1 z2)):
>
> (match '((x) (y y0) (z z1 z2)):
>    (((heads tails ...) ...)
>     heads))
>
> > If you look at the example, it should be clear what this illustrates
> > while the other lacks, it seems obvious and im unsure what your are
> > missing tbh.
>
> Aside from the inlining, it absolutely isn't clear.  Aside from the
> inlining, your new example is less clear to me -- e.g., why does 'tails'
> have ,@ and 'head' have ',', instead of both having ',@' or both having
> ','?
>
> What I'm missing is, why did you change
>
>    (((heads tails ...) ...)
>     heads))
>
> to
>
>    (((head ...) tails ...)
>     `(,@tails ,head)))
>
> ?
>

1st, an aside: none of this actually matters. These come from commits at
the beginning of the patch set. This was first draft. The final examples i
proposed for the docs are much nicer.

That you demand answers about what c/sould be autosquashed in a rebase with
no loss of valuable commits, along with the fact that this pattern recurred
at the first sight of my return makes me think you have a chip on your
shoulder.

>
Regardless, the lesson is clear. Let me explain, because it could help you
to understand how to read the patch set

It would help if you actually look at my example:

(match '(((a b c) e f g) 1 2 3)
                (((head ...) tails ...)
                `(,@tails ,head)))

      => (1 2 3 ((a b c) e f g))

What does this demonstrate? Look at the before and after. Its pretty
simple. It shows that a reversed splice/unquote pattern can be used as the
basis for rotating nested forms in place,  an often desirable operation
considering it preserves some structure.

On the contrary, without splicing we would have:
((1 2 3) ((a b c) e f g)

But it doesn't really matter, this should be autosquashed.

>
> If it is clear and obvious to you what this change is for, then please
> actually say what it is for instead of stating that it is obvious.
>
> AFAIK, the presentation did not explain what this (*non-inlining*)
> change is for.  If it did, then you need to say at which minute+second
> -- unlike text, you can't really skim through videos.
>
> <b>: the presentation didn't specify which forms are and aren't used, it
> only specified the kinds of changes that would be applied, with a few
> general examples that aren't as good as the ones I've presented.


> >      > +A pattern matcher can match an object against several patterns
> and
> >      > +extract the elements that make it up.
> >      > +
> >      > +@example
> >      > +(let ((m '((a . b) (c . d) (e . f))))
> >      > +  (match m
> >      > +    (((left . right) ...) left)))
> >      > +@result{} (a c e)
> >      > +@end example
> >
> >     There is only a single pattern here, not several patterns.
> >     Several patterns would be, e.g.,
> >
> >
> >     (let ((m '(#(a b) #(c d) #(e f)))
> >         (match m
> >           (((left . right) ...) left)
> >           ((#(left right) ...) left))).
> >
> >
> > Sorry, but you are wrong. What you are calling patterns are pattern
> > clauses. Left and right here are pattern variables bound to patterns.
> > See SRFI-204 on the Shinn Pattern matcher which (ice-9 match) more or
> > less implements https://srfi.schemers.org/srfi-204/srfi-204.html
> > <https://srfi.schemers.org/srfi-204/srfi-204.html>
>
> OK, terminology difference.


No, this is a precise semantic difference.

It's still wrong though, in a different way
> -- you write that an object is matched against several patterns.
> However, there is no 'or', 'and' or multiple clauses anywhere in your
> example, so the object ((a . b) (c . d) (e . f)) is only matched against
> a single pattern (((left . right) ...) left), and likewise its elements
> (a . b), (c . d), ... are only matched against a single clause (left .
> right), etc..
>

You're again conflating patterns with pattern clauses. Left names a pattern
that binds to the list of all left associations, right binds a list of all
of the right associations. A pattern = a sequence of locations; its the
sequence a generic pattern variable "represents". The a variable in the
position of the 3rd element of the left branch of a tree will bind to all
the objects there for every tree, regardless of the data type if you use
generic pattern variables. A pattern clause is a sequence of pattern
variable.


> Proposal: 'several patterns -> a pattern' (which happens to consist of
> smaller patterns).
>
>
> ~ Why? If we start mixing and matching

~  all these subtly different terms used

~ to specify Scheme to suit our

~ vibes, how are we going to actually

~ discuss the language, how it works

~ and how to grow it? Tbh this kind

~ thinking is a recipe for unclear docs

>
> >      > +Patterns can represent any Scheme object: lists, strings,
> symbols,
> >      > +records, etc.
> >
> >     Missing end-of-sentence period. The . in 'etc.' is part of the
> >     abbreviation 'etc.', not an end-of-sentence marker.  I know it's
> >     'standard' English (for some value of 'standard' in English) to
> >     conflate
> >     all the dots, but we don't have to follow standard when they are
> buggy.
> >
> >     (This is like the example at
> >     <https://catb.org/jargon/html/writing-style.html
> >     <https://catb.org/jargon/html/writing-style.html>> about not moving
> the
> >     end-of-sentence period inside quotation marks:
> >
> >           Then delete a line from the file by typing “dd”.
> >
> >           Then delete a line from the file by typing “dd.”
> >
> >     -- while in this particular case (i.e., 'etc.') the distinction is
> >     unimportant, for consistency with other cases where the distinction
> is
> >     important, I would go for '..., symbols, records, etc..'.
>

Huh?

> >
> >
> > I'm sorry but again, this is simply bad style and incorrect suggestions.
> > According to the MLA, the authority on English style:
>
> It appears to be _an_ authority, but certainly not _the_ authority.
> I believe it's common knowledge there is no central authority on English.


👍

>
> > "A sentence should never have two periods at the end. If a sentence ends
> > with an abbreviation followed by a period, do not add an additional
> period:
> >
>  >
> >     She explained the rules for periods, commas, semicolons, etc."
> >
> > Thats MLA's example of the correct way of how to end a sentence with
> > punctuated abbreviation.
>
> It appears you disagree that dots shouldn't be merged, but you aren't
> giving a proper argument for your position or a counter-argument to my
> argument -- with your reference to MLA, you were making an appeal to
> authority, which on its own is an argument, but:
>

Its really simple actually, we're working on stuff other people need to
read and therefore shouldn't add nonsense adhoc notation like dd..


>    * I already anticipated the potential argument:
>     ‘I know it's 'standard' English (for some value of 'standard' in
>      English) to conflate all the dots, but ...’.
>
>      (In this case, 'standard' = 'MLA', though it would apply to
>      many other authorities too.)
>
>      -- you aren't saying anything new here.
>

No, I'm not, I'm being totally boring and normal in this regard because
collectively authored documentation is something you should never adopt
non-standard writing notation in the course of authoring, just to one up
someone on a mailing list.

To be honest, it's this kind of attitude that has resulted in the current
docs that so many people find utterly incomprehensible. The core point of
my talk that what makes Info Guile so hard to read is the lack of stylistic
consistency. Editors and editing exist for a very good reason.


 I'm just saying be should use sensible standard punctuation, when someone
says "i want to use this that would

   * I also already refuted it (‘but ... This is like the example at
>      ...’, with a link to a document that explains in some detail the
>      reasoning behind it.)
>

Why? Who does it even benefit except you? You give no reasons for any of
these bizarre grips you hope to keep the documentation locked in, beyond
the fact that its how u do it.


>
>    * You can't counter an argument by authority (in my case, the
>      Jargon file) by another argument by authority (in your case,
>      the MLA).  Instead you need to argue which one of the authorities
>      is right or wrong -- the fragment of the Jargon file I referred
>      to gives some explanation, whereas your quote of the MLA just
>      states things without explaining a thing, so the Jargon file
>      'wins' by default.
>

Me. I'm correct. I did PhD under the supervision  of Alain Badiou for
Christ's sakes. I used to teach and grade papers. I've published in
international journals. We don't need to be strict but cmon man this
doesn't even make any sense.

>
> You could instead quote a part of the MLA style guide that actually
> explains ‘why merging periods is good’ (I doubt such an explanation in
> the MLA style guide actually exists but I could be pleasantly
> surprised), or say something like 'While in some rare situations,
> potential confusion might exist, I still prefer merging periods, and in
> matters of taste there can be no disputes.', but not this.
>

No, at MLA or anywhere ever said merged periods are good because merged
periods aren't a real thing. I just googled it.

Goodnight, sorry but I'd like to ask you refrain from reviewing my patches
in the future, I dont have the time to deal with this nonsense.


> Greetings,
> Maxime.j
>