[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 1/6] docs/match: add pattern matching examples

From: Blake Shaw
Subject: Re: [PATCH v1 1/6] docs/match: add pattern matching examples
Date: Mon, 30 Jan 2023 07:49:20 +0700

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:

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:

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 <> 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 ...) ...)

> 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 ...) ...)


   (((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
> <>

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
>     <
>     <>> 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..'.

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]