From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Blake Shaw Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH v1 1/6] docs/match: add pattern matching examples Date: Mon, 30 Jan 2023 07:49:20 +0700 Message-ID: References: <20230126185801.19064-1-blake@reproduciblemedia.com> <9a5ee863-c768-4109-3323-908adc277479@telenet.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b7a9b905f37096a5" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35853"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Jan 30 01:50:24 2023 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pMINL-00095V-Nt for guile-devel@m.gmane-mx.org; Mon, 30 Jan 2023 01:50:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMIMj-0005Gu-8u; Sun, 29 Jan 2023 19:49:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMIMe-0005Gb-Of for guile-devel@gnu.org; Sun, 29 Jan 2023 19:49:43 -0500 Original-Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pMIMa-0002Pu-6S for guile-devel@gnu.org; Sun, 29 Jan 2023 19:49:39 -0500 Original-Received: by mail-yb1-xb29.google.com with SMTP id d132so12253048ybb.5 for ; Sun, 29 Jan 2023 16:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sweatshoppe-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jJe13AOUTxXXrTjtVouVdhUPunm+q2t71MZZR+3n2Z0=; b=hm+ZbBxXU8wTT/e+PqkZOF4pkEwb/asS+jFZZDYPj6znaX7x+gyLqhCUm9JU9jZ/tm PU1oDMcN3TGby+iWak7+lbiRM+NWygpmkqmk2wL6A/zwGhK2+i82rD1ufOGnJFZemI0d v3hQvU04K70QQnABSss/VNJSJSDgcWBUPnWiMNskotdpSjWXMn7H/m4UBMVvNyLq/+Kt ODqlETQhLwzqxPilBXLuyD/700AoqhKbq4GG/y1IMRaMM/guc9iQuIoSW8YIUXfna9VI EWrA5yk9aYtnvFCKfkjYtIJVFM2AQJgFqgnIJN5VRRLhXeCv3xB+F0Z4SMhtCz3b99TL Y4Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jJe13AOUTxXXrTjtVouVdhUPunm+q2t71MZZR+3n2Z0=; b=WleqkY6exBOSRBB6c7o9mpHUAb+ANYEMgOTHj+WR4NI7SaGKBP2A1OVbprvIcge6jv hXVXh+3QtYbpnLF/prd4E9jeQp8owSbp49LeZXQ9WVVZLsZDQ+hWIYpjWPDqYHtXlbi4 aau/ZSe/pCVVrz7qDLRFRiSQVzqmW8pPJF88REpWp5XkdwduXHzfDAhGpgkbRWOV9piI 6Y6jXaooiNvZjz5h8kUNewYmYpNUuA62p61HSY+nJ3io+B2Vby4AzEZPYoUMfTdgihVN LW9AG7DD8rAM3CjVdK0+0EsZml+p2xy1OC/7P7Gct4zHD6jz7c0ZVSM0E3sfkBeuVHhg Q7fw== X-Gm-Message-State: AFqh2kr9GTcVy8FspcLmcCEM7QlDiOW/K0lbBn/VySfOAEfh8vRQSwE4 VIZodkOONOo7uyttyVej4/o9B2bUFut1zUntwn67IFgYv6LSzx9K X-Google-Smtp-Source: AMrXdXu+XRj54q5CsYydIsIL8umh/DjxGhOykcdQvpVOqIqodffiyZYL1bZtGJl8qvdVNFqvoO5R8PRyNezQn+a/B2k= X-Received: by 2002:a25:3c45:0:b0:7d5:f6e1:4e08 with SMTP id j66-20020a253c45000000b007d5f6e14e08mr4453967yba.441.1675039774053; Sun, 29 Jan 2023 16:49:34 -0800 (PST) In-Reply-To: <9a5ee863-c768-4109-3323-908adc277479@telenet.be> Received-SPF: none client-ip=2607:f8b0:4864:20::b29; envelope-from=blake@sweatshoppe.org; helo=mail-yb1-xb29.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21662 Archived-At: --000000000000b7a9b905f37096a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 matter= s > > 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 =E2=80=98**aside fr= om > inlining** 'lst', what's this change for?=E2=80=99 (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 =3D '((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))) =3D> (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. > > : 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 > > > > 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 =3D 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 =E2=80=9Cdd=E2=80= =9D. > > > > Then delete a line from the file by typing =E2=80=9Cdd.=E2=80= =9D > > > > -- 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. =F0=9F=91=8D > > > "A sentence should never have two periods at the end. If a sentence end= s > > 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: > =E2=80=98I know it's 'standard' English (for some value of 'standard'= in > English) to conflate all the dots, but ...=E2=80=99. > > (In this case, 'standard' =3D '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 (=E2=80=98but ... This is like the example a= t > ...=E2=80=99, 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 =E2=80=98why merging periods is good=E2=80=99 (I doubt such an e= xplanation 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 > --000000000000b7a9b905f37096a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Maxime,

I have to be perfectly up-front: pa= st interactions like this, which appear to me as more or less a means to ga= tekeep the contribution process by tying up others' time in disagreemen= t 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 commun= ity have shared similar frustrations that have caused them to become detach= ed from the project as well.

If we look at the last time I posted to the list 6 months ago, I was h= oping to offer some simple contributions: proof reading edits for additions= to the docs, which I was actively working on at the time:=C2=A0https://lists.gnu.org/archive/html/guix-deve= l/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 m= otivated more by the desire to argue rather than to collaborate on improvin= g Guix to the best of our abilities. You even mention in your first reply t= hat the sequence of examples is "presumably" better, implying you= didn't take the time to even work through the interlocking contents, p= referring rather to shoot down the contribution.
But im surely just being cranky over a one off min= or dispute from 6 months ago, right? Let's look back at my previous pos= ting 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 "docu= mentation 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 i= f 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/Gu= ix community until I started hanging out on Mastodon and discovered many gu= ix have retreated there.

Now let's get into the specifics of the current patch review where I&#= 39;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:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 26-01-2023 19:57, Blake Shaw wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0@example
>=C2=A0 =C2=A0 =C2=A0 > -(match lst
>=C2=A0 =C2=A0 =C2=A0 > -=C2=A0 (((heads tails ...) ...)
>=C2=A0 =C2=A0 =C2=A0 > -=C2=A0 =C2=A0heads))
>=C2=A0 =C2=A0 =C2=A0 > +(match '(((a b c) e f g) 1 2 3)
>=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 (((head ...) tails ...)
>=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0`(,@tails ,head)))
>=C2=A0 =C2=A0 =C2=A0 > +@result{} (1 2 3 ((a b c) e f g))
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0@end example
>
>
>=C2=A0 =C2=A0 =C2=A0 >>Contrary to the commit message, this >&= gt;isn't an addition of a
>=C2=A0 =C2=A0 =C2=A0pattern
>=C2=A0 =C2=A0 =C2=A0 >>matching example, it's a change.
>=C2=A0 =C2=A0 =C2=A0 >>Aside from inlining 'lst', what= 9;s this >>change for?
>
>
> The offered example cant be executed. Its up to the reader to figure <= br> > out, which isn't valuable to anyone trying to understand the match= er in
> first place. Again, ee the linked presentation for much on these matte= rs
> and more.

There's a lot going on in what follows so let's take a lo= ok.

The offered example indeed can't be executed.=C2=A0 However, inlining &= #39;lst'
is sufficient to make it execute (*), and I asked for =E2=80=98**aside from=
inlining** 'lst', what's this change for?=E2=80=99 (emphasis ad= ded)

1. You first admit that the origina= l example cant execute. We agreed on guix days that examples should work wi= thout users having to put the pieces together themselves. Its therefore obv= ious that a change is required, whether or not you said **aside from inlini= ng**. The old examples were agreed to be poor and insufficient. My contribu= tion 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 f= inal result improves the pattern matching section by leaps and bounds.

2. You claim that it would b= e sufficient to "inline" lst. Even if this were correct, which it= isn't because `@,any-bound-identifier is an incorrect application of q= uasiquotation excepting defmacro (quasiquoting the unquote-splicing of a bo= und identifier va always results in a list of the form (unquote-splicing va= r) because at that point you merely quoted the datum unquote-splicing. unqu= ote-splicing has to splice at a nonterminal location of an ordered form lik= e lists or arrays and thus performs the same function as periods that aren&= #39;t in dotted tail position)... what is the pedogagogical value of showin= g that? If it did work as you expect, what would it impart on the reader? N= othing except perhaps that unquote-splicing exists, while my example actual= ly demonstrates important, subtle properties of match that would apparently= be valuable for you to take the time to actually read and comprehend, whic= h is part of your duty as a reviewer in the first place.


(*) E.g. take lst =3D '((x) (y y0) (z z1 z2)):

(match '((x) (y y0) (z z1 z2)):
=C2=A0 =C2=A0(((heads tails ...) ...)
=C2=A0 =C2=A0 heads))

> If you look at the example, it should be clear what this illustrates <= br> > while the other lacks, it seems obvious and im unsure what your are > missing tbh.

Aside from the inlining, it absolutely isn't clear.=C2=A0 Aside from th= e
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

=C2=A0 =C2=A0(((heads tails ...) ...)
=C2=A0 =C2=A0 heads))

to

=C2=A0 =C2=A0(((head ...) tails ...)
=C2=A0 =C2=A0 `(,@tails ,head)))

?

1st, an aside: none of this actually matters. = These come from commits at the beginning of the patch set. This was first d= raft. 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, alon= g 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 ho= w 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)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (((head .= ..) tails ...)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 `= (,@tails ,head)))

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

<= /div>
What does this demonstrate? Look at the before and a= fter. Its pretty simple. It shows that a reversed splice/unquote pattern ca= n be used as the basis for rotating nested forms in place,=C2=A0 an often d= esirable operation considering it preserves some structure.

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

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.=C2=A0 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, i= t only specified the kinds of changes that would be applied, with a few gen= eral examples that aren't as good as the ones I've presented.
<= br> >=C2=A0 =C2=A0 =C2=A0 > +A pattern matcher can match an object agains= t several patterns and
>=C2=A0 =C2=A0 =C2=A0 > +extract the elements that make it up.
>=C2=A0 =C2=A0 =C2=A0 > +
>=C2=A0 =C2=A0 =C2=A0 > +@example
>=C2=A0 =C2=A0 =C2=A0 > +(let ((m '((a . b) (c . d) (e . f)))) >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 (match m
>=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 (((left . right) ...) left)))<= br> >=C2=A0 =C2=A0 =C2=A0 > +@result{} (a c e)
>=C2=A0 =C2=A0 =C2=A0 > +@end example
>
>=C2=A0 =C2=A0 =C2=A0There is only a single pattern here, not several pa= tterns.
>=C2=A0 =C2=A0 =C2=A0Several patterns would be, e.g.,
>
>
>=C2=A0 =C2=A0 =C2=A0(let ((m '(#(a b) #(c d) #(e f)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(match m
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(((left . right) ...) left) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0((#(left right) ...) left))).<= br> >
>
> 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://s= rfi.schemers.org/srfi-204/srfi-204.html
> <https://srfi.scheme= rs.org/srfi-204/srfi-204.html>

OK, terminology difference.=C2=A0

<= /div>
No, th= is 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 anywhe= re 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 name= s a pattern that binds to the list of all left associations, right binds a = list of all of the right associations. A pattern =3D a sequence of location= s; 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 t= ype if you use generic pattern variables. A pattern clause is a sequence of= pattern variable.


Proposal: 'several patterns -> a pattern' (which happens to cons= ist of
smaller patterns).


~ Why? If we start mixi= ng and matching
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">~=C2=A0 all these subtly d= ifferent terms used
~ to specify Scheme to suit our
~ vibes, how are we going to actually
~ discuss the language, how it works
~ an= d how to grow it? Tbh this kind=C2=A0
~ th= inking is a recipe for unclear docs
>
>=C2=A0 =C2=A0 =C2=A0 > +Patterns can represent any Scheme object: li= sts, strings, symbols,
>=C2=A0 =C2=A0 =C2=A0 > +records, etc.
>
>=C2=A0 =C2=A0 =C2=A0Missing end-of-sentence period. The . in 'etc.&= #39; is part of the
>=C2=A0 =C2=A0 =C2=A0abbreviation 'etc.', not an end-of-sentence= marker.=C2=A0 I know it's
>=C2=A0 =C2=A0 =C2=A0'standard' English (for some value of '= standard' in English) to
>=C2=A0 =C2=A0 =C2=A0conflate
>=C2=A0 =C2=A0 =C2=A0all the dots, but we don't have to follow stand= ard when they are buggy.
>
>=C2=A0 =C2=A0 =C2=A0(This is like the example at
>=C2=A0 =C2=A0 =C2=A0<htt= ps://catb.org/jargon/html/writing-style.html
>=C2=A0 =C2=A0 =C2=A0<htt= ps://catb.org/jargon/html/writing-style.html>> about not moving t= he
>=C2=A0 =C2=A0 =C2=A0end-of-sentence period inside quotation marks:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Then delete a line from the fi= le by typing =E2=80=9Cdd=E2=80=9D.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Then delete a line from the fi= le by typing =E2=80=9Cdd.=E2=80=9D
>
>=C2=A0 =C2=A0 =C2=A0-- while in this particular case (i.e., 'etc.&#= 39;) the distinction is
>=C2=A0 =C2=A0 =C2=A0unimportant, for consistency with other cases where= the distinction is
>=C2=A0 =C2=A0 =C2=A0important, I would go for '..., symbols, record= s, etc..'.

Huh?=C2=A0
>
>
> I'm sorry but again, this is simply bad style and incorrect sugges= tions.
> 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 Englis= h.

=F0=9F=91=8D=C2=A0

> "A sentence should never have two periods at the end. If a senten= ce ends
> with an abbreviation followed by a period, do not add an additional pe= riod:
>
=C2=A0>
>=C2=A0 =C2=A0 =C2=A0She explained the rules for periods, commas, semico= lons, etc."
>
> Thats MLA's example of the correct way of how to end a sentence wi= th
> 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= 9;re working on stuff other people need to read and therefore shouldn't= add nonsense adhoc notation like dd..


=C2=A0 =C2=A0* I already anticipated the potential argument:
=C2=A0 =C2=A0 =E2=80=98I know it's 'standard' English (for some= value of 'standard' in
=C2=A0 =C2=A0 =C2=A0English) to conflate all the dots, but ...=E2=80=99.
=C2=A0 =C2=A0 =C2=A0(In this case, 'standard' =3D 'MLA', th= ough it would apply to
=C2=A0 =C2=A0 =C2=A0many other authorities too.)

=C2=A0 =C2=A0 =C2=A0-- 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 wri= ting notation in the course of authoring, just to one up someone on a maili= ng list.

To be honest, i= t'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.
<= br>

=C2=A0I'm just s= aying be should use sensible standard punctuation, when someone says "= i want to use this that would

=C2=A0 =C2=A0* I also already refuted it (=E2=80=98but ... This is like the= example at
=C2=A0 =C2=A0 =C2=A0...=E2=80=99, with a link to a document that explains i= n some detail the
=C2=A0 =C2=A0 =C2=A0reasoning 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 d= ocumentation locked in, beyond the fact that its how u do it.=C2=A0



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

Me. I'm correct. I did PhD unde= r the supervision=C2=A0 of Alain Badiou for Christ's sakes. I used to t= each 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.= =C2=A0

You could instead quote a part of the MLA style guide that actually
explains =E2=80=98why merging periods is good=E2=80=99 (I doubt such an exp= lanation 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 anywh= ere ever said merged periods are good because merged periods aren't a r= eal thing. I just googled it.

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


Greetings,
Maxime.j
--000000000000b7a9b905f37096a5--