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

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

[Blake Shaw]

Hello all,

This commit introduces a set of (long overdue) examples to the
documentation on pattern matching discussed in the Guix Days
presentation which can be found here:
https://xana.lepiller.eu/guix-days-2022/guix-days-2022-documentation.mp4

As discussed in the Guix Days presentation, and agreed upon during the
corresponding brainstorming session, I'm introducing a set of examples
that intend to demonstrate the basics of the Shinn/Wright pattern
matcher, as well as touch on some of its subtleties.

Most paragraphs will be broken up into smaller peices with examples
interspersed throughout, according to the refactoring strategy of
"graduated expression" presented in my talk. The goal is to express the
pedagogical aim of examples naturally through graduality, reducing
"wordiness" primarily by with examples rather than reducing what has
already been written.

My apologies for taking so long to get to work on this! This summer
I was confronted with a unanticipated event that subsequently turned
my life upside down, causing my contributions to be low. I hope to be
increasing my contributions from here on, and fulfilling my obligations
concerning the documentation.

Best,
Blake

---
 doc/ref/match.texi | 138 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 99 insertions(+), 39 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index f5ea43118..105150886 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -24,52 +24,66 @@ written by Alex Shinn, and compatible with Andrew K. Wright's pattern
 matcher found in many Scheme implementations.
 
 @cindex pattern variable
-A pattern matcher can match an object against several patterns and
-extract the elements that make it up.  Patterns can represent any Scheme
-object: lists, strings, symbols, records, etc.  They can optionally contain
-@dfn{pattern variables}.  When a matching pattern is found, an
-expression associated with the pattern is evaluated, optionally with all
-pattern variables bound to the corresponding elements of the object:
+A pattern matcher does precisely what the name implies: it matches
+some arbitrary pattern, and returns some result accordingly.
 
 @example
-(let ((l '(hello (world))))
-  (match l           ;; <- the input object
-    (('hello (who))  ;; <- the pattern
-     who)))          ;; <- the expression evaluated upon matching
-@result{} world
+(define (english-base-ten->number name)
+  (match name
+    ('zero   0)
+    ('one    1)
+    ('two    2)
+    ('three  3)
+    ('four   4)
+    ('five   5)
+    ('six    6)
+    ('seven  7)
+    ('eight  8)
+    ('nine   9)))
+      
+(english-base-ten->number 'six)
+@result{} 6
+
+(apply + (map english-base-ten->number '(one two three four)))
+@result{} 10 
 @end example
 
-In this example, list @var{l} matches the pattern @code{('hello (who))},
-because it is a two-element list whose first element is the symbol
-@code{hello} and whose second element is a one-element list.  Here
-@var{who} is a pattern variable.  @code{match}, the pattern matcher,
-locally binds @var{who} to the value contained in this one-element
-list---i.e., the symbol @code{world}.  An error would be raised if
-@var{l} did not match the pattern.
-
-The same object can be matched against a simpler pattern:
+Pattern matchers may contain @dfn{pattern variables}, local bindings
+to all elements that match a pattern.
 
 @example
-(let ((l '(hello (world))))
-  (match l
-    ((x y)
-     (values x y))))
-@result{} hello
-@result{} (world)
+(let re ((ns '(one two three four ten))
+         (total 0)) 
+  (match ns
+    ((e) (+ total (english-base-ten->number e)))
+    ((e . es) 
+     (re es (+ total (english-base-ten->number e))))))
+@result{} 20
 @end example
 
-Here pattern @code{(x y)} matches any two-element list, regardless of
-the types of these elements.  Pattern variables @var{x} and @var{y} are
-bound to, respectively, the first and second element of @var{l}.
-
-Patterns can be composed, and nested.  For instance, @code{...}
+In this example, the list @var{ns} matches the pattern
+@code{(e . es)}, where the pattern variable @var{e} corresponds 
+to the `car` of @var{ns} and the pattern variable @var{es}
+corresponds to the `cdr` of @var{ns}.
+
+A tail call @code{re} is then initiated and we `cdr` down the
+list by recurring on the tail @var{es}, applying our matcher
+@code{english-base-ten->number} to each element of @var{ns} until
+only a single element @code{(e)} remains, causing the @var{total}
+to be computed.  In modern Scheme programming it is common to use
+@code{match} in place of the more verbose but familiar combination
+of @code{cond}, @code{car} and @code{cdr}, so it's important to
+understand how these idioms translate. 
+
+Patterns can be composed and nested.  For instance, @code{...}
 (ellipsis) means that the previous pattern may be matched zero or more
 times in a list:
 
 @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
 
 @noindent
@@ -79,6 +93,52 @@ lst)}.  However, it performs additional checks to make sure that
 @var{lst} and the lists therein are proper lists, as prescribed by the
 pattern, raising an error if they are not.
 
+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
+
+@example
+(let ((m '((1 . (a . b)) (2 . (c . d)) (3 . (e . f)))))
+  (match m
+    (((key . (left . right)) ...) 
+     (fold-right acons '() key right ))))
+@result{} ((1 . b) (2 . d) (3 . f))
+@end example
+
+Patterns can represent any Scheme object: lists, strings, symbols,
+records, etc.
+
+@example
+(let re ((m #(a "b" c "d" e "f" g)))
+   (match m
+     ((or (e) #(e)) e)
+     ((or #(e1 e2 es ...)
+	   (e1 e2 es ...)) 
+       (cons (cons e1 e2)
+ 	     (re es)))))
+@result{} ((a . "b") (c . "d") (e . "f") . g) 
+@end example
+
+When a matching pattern is found, an expression associated with the
+pattern is evaluated, optionally with all pattern variables bound to
+the corresponding elements of the object.
+
+@example
+(let re ((m '(a b c d e f g h i)))
+   (match m
+     ((e) e)
+     ((e1 e2 es ...) 
+      (acons e1 e2
+ 	     (re es)))))
+@result{} ((a . b) (c . d) (e . f) (g . h) . i)
+@end example
+
 Compared to hand-written code, pattern matching noticeably improves
 clarity and conciseness---no need to resort to series of @code{car} and
 @code{cdr} calls when matching lists, for instance.  It also improves
@@ -229,11 +289,11 @@ expressions.
 @end deffn
 
 @example
-((match-lambda
-   (('hello (who))
-    who))
- '(hello (world)))
-@result{} world
+(define flatten-singletons 
+   (match-lambda (((s) ...) s)))
+
+(flatten-singletons '((x) (y) (z)))
+@result{} (x y z) 
 @end example
 
 @deffn {Scheme Syntax} match-lambda* clause1 clause2 @dots{}
-- 
2.39.1

[PATCH v1 2/6] docs/match: rm unquote-splicing as it interferes with textinfo

[Blake Shaw]

don't know how to fix this rn, but...
---
 doc/ref/match.texi | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index 105150886..c5017e1a5 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -80,10 +80,10 @@ Patterns can be composed and nested.  For instance, @code{...}
 times in a list:
 
 @example
-(match '(((a b c) e f g) 1 2 3)  
-  (((head ...) tails ...)
-   `(,@tails ,head)))
-@result{} (1 2 3 ((a b c) e f g))
+(match lst
+  (((heads tails ...) ...)
+     heads))
+@result{} 
 @end example
 
 @noindent
@@ -97,10 +97,11 @@ 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))))
+(let ((m '((l1 . r1) (l2 . r2) (l3 . r3))))
   (match m
-    (((left . right) ...) left)))
-@result{} (a c e)
+    (((left . right) ...) 
+     (list left right)))) 
+@result{} ((l1 l2 l3) (r1 r2 r3))
 @end example
 
 @example
-- 
2.39.1

Re: [PATCH v1 2/6] docs/match: rm unquote-splicing as it interferes with textinfo

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 631 bytes --]



On 26-01-2023 19:57, Blake Shaw wrote:
> don't know how to fix this rn, but...

You can escape @ with @@.

> ---
>   doc/ref/match.texi | 15 ++++++++-------
>   1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/ref/match.texi b/doc/ref/match.texi
> index 105150886..c5017e1a5 100644
> --- a/doc/ref/match.texi
> +++ b/doc/ref/match.texi
> @@ -80,10 +80,10 @@ Patterns can be composed and nested.  For instance, @code{...}
>   times in a list:
>   
>   @example
> -(match '(((a b c) e f g) 1 2 3)
> -  (((head ...) tails ...)
> -   `(,@tails ,head)))

E.g.: (,@@tails ,head) (untested)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v1 2/6] docs/match: rm unquote-splicing as it interferes with textinfo

[Blake Shaw]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

Thanks! The new latest edit is still preferred but I'll keep that in mind
for the future.

On Fri, Jan 27, 2023, 23:33 Maxime Devos <maximedevos@telenet.be> wrote:

>
>
> On 26-01-2023 19:57, Blake Shaw wrote:
> > don't know how to fix this rn, but...
>
> You can escape @ with @@.
>
> > ---
> >   doc/ref/match.texi | 15 ++++++++-------
> >   1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/doc/ref/match.texi b/doc/ref/match.texi
> > index 105150886..c5017e1a5 100644
> > --- a/doc/ref/match.texi
> > +++ b/doc/ref/match.texi
> > @@ -80,10 +80,10 @@ Patterns can be composed and nested.  For instance,
> @code{...}
> >   times in a list:
> >
> >   @example
> > -(match '(((a b c) e f g) 1 2 3)
> > -  (((head ...) tails ...)
> > -   `(,@tails ,head)))
>
> E.g.: (,@@tails ,head) (untested)
>

[-- Attachment #2: Type: text/html, Size: 1230 bytes --]

Re: [PATCH v1 2/6] docs/match: rm unquote-splicing as it interferes with textinfo

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 492 bytes --]



On 28-01-2023 10:14, Blake Shaw wrote:
> Thanks! The new latest edit is still preferred but I'll keep that in 
> mind for the future.

I don't follow? The commit message was:

> [PATCH v1 2/6] docs/match: rm unquote-splicing as it interferes with textinfo
> don't know how to fix this rn, but...

I.e., this commit is just a work-around for broken Texinfo markup.  Why 
would you settle for a work-around when a fix (i.e. @@ instead of @) is 
available?

Greetings,
Maime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v1 2/6] docs/match: rm unquote-splicing as it interferes with textinfo

[Blake Shaw]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

Because the result in the final commit is better. Sorry, I should have
added this commit to fixup when I was rebasing.

On Sat, Jan 28, 2023, 20:08 Maxime Devos <maximedevos@telenet.be> wrote:

>
>
> On 28-01-2023 10:14, Blake Shaw wrote:
> > Thanks! The new latest edit is still preferred but I'll keep that in
> > mind for the future.
>
> I don't follow? The commit message was:
>
> > [PATCH v1 2/6] docs/match: rm unquote-splicing as it interferes with
> textinfo
> > don't know how to fix this rn, but...
>
> I.e., this commit is just a work-around for broken Texinfo markup.  Why
> would you settle for a work-around when a fix (i.e. @@ instead of @) is
> available?
>
> Greetings,
> Maime.
>

[-- Attachment #2: Type: text/html, Size: 1043 bytes --]

[PATCH v1 3/6] docs/match: add reverse nested list example

[Blake Shaw]

---
 doc/ref/match.texi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index c5017e1a5..567146a35 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -112,6 +112,13 @@ extract the elements that make it up.
 @result{} ((1 . b) (2 . d) (3 . f))
 @end example
 
+@example
+(match '(((a b c) e f g) 1 2 3)  
+  ((((head ...) . rest) tails ...)
+   (acons tails head rest )))
+@result {} (((1 2 3) a b c) e f g)
+@end example
+
 Patterns can represent any Scheme object: lists, strings, symbols,
 records, etc.
 
@@ -135,8 +142,7 @@ the corresponding elements of the object.
    (match m
      ((e) e)
      ((e1 e2 es ...) 
-      (acons e1 e2
- 	     (re es)))))
+      (acons e1 e2 (re es)))))
 @result{} ((a . b) (c . d) (e . f) (g . h) . i)
 @end example
 
-- 
2.39.1

[PATCH v1 4/6] docs/match: match-let* unwrap example

[Blake Shaw]

[pdf] now builds, but there are some spacing issues I want to correct
in the PDF, that will be introduced next.
---
 doc/ref/match.texi | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index 567146a35..4f3dc86fc 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -248,7 +248,7 @@ The names @code{quote}, @code{quasiquote}, @code{unquote},
 @code{or}, @code{not}, @code{set!}, @code{get!}, @code{...}, and
 @code{___} cannot be used as pattern variables.
 
-Here is a more complex example:
+Here is a more complex example using records and promises:
 
 @example
 (use-modules (srfi srfi-9))
@@ -361,11 +361,22 @@ bind the variables in sequence, with preceding match variables in scope.
 (match-let (((x y) (list 1 2)))
   (match-let (((a b) (list x 4)))
     (list a b x y)))
-@result{}
-(1 4 1 2)
+@result{} (1 4 1 2)
 @end example
 @end deffn
 
+@example
+(define wrap '(((((unnest arbitrary nestings))))))
+
+(let unwrap ((peel wrap)) 
+  (match-let* ([([core ...]) peel]
+	       [(wrapper ...) core])
+    (if (> (length wrapper) 1) 
+	wrapper 
+	(unwrap wrapper))))
+@result{} (unnest arbitrary nestings)
+@end example
+
 @deffn {Scheme Syntax} match-letrec ((variable expression) @dots{}) body
 Similar to @code{match-let}, but analogously to @code{letrec}, match and
 bind the variables with all match variables in scope.
-- 
2.39.1

[PATCH v1 5/6] docs/fixup: @cindex was in the wrong place

[Blake Shaw]

---
 doc/ref/match.texi | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index 4f3dc86fc..5512103c4 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -23,11 +23,11 @@ The @code{(ice-9 match)} module provides a @dfn{pattern matcher},
 written by Alex Shinn, and compatible with Andrew K. Wright's pattern
 matcher found in many Scheme implementations.
 
-@cindex pattern variable
 A pattern matcher does precisely what the name implies: it matches
 some arbitrary pattern, and returns some result accordingly.
 
-@example
+@lisp
+
 (define (english-base-ten->number name)
   (match name
     ('zero   0)
@@ -40,14 +40,21 @@ some arbitrary pattern, and returns some result accordingly.
     ('seven  7)
     ('eight  8)
     ('nine   9)))
+
+@end lisp
       
+@lisp
 (english-base-ten->number 'six)
+
 @result{} 6
+@end lisp
 
+@lisp
 (apply + (map english-base-ten->number '(one two three four)))
 @result{} 10 
-@end example
+@end lisp 
 
+@cindex pattern variable
 Pattern matchers may contain @dfn{pattern variables}, local bindings
 to all elements that match a pattern.
 
-- 
2.39.1

[PATCH v1 6/6] docs/match:style reviewing with pdf, adding newlines

[Blake Shaw]

---
 doc/ref/match.texi | 78 ++++++++++++++++++++++++++++------------------
 1 file changed, 47 insertions(+), 31 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index 5512103c4..38745e173 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -19,15 +19,15 @@
 @cindex pattern matching
 @cindex (ice-9 match)
 
-The @code{(ice-9 match)} module provides a @dfn{pattern matcher},
+@* The @code{(ice-9 match)} module provides a @dfn{pattern matcher},
 written by Alex Shinn, and compatible with Andrew K. Wright's pattern
 matcher found in many Scheme implementations.
 
-A pattern matcher does precisely what the name implies: it matches
-some arbitrary pattern, and returns some result accordingly.
-
-@lisp
+@* @noindent A pattern matcher does precisely what the name implies: it
+matches some arbitrary pattern, and returns some result accordingly.
 
+@*
+@example
 (define (english-base-ten->number name)
   (match name
     ('zero   0)
@@ -40,40 +40,43 @@ some arbitrary pattern, and returns some result accordingly.
     ('seven  7)
     ('eight  8)
     ('nine   9)))
-
-@end lisp
+@end example
       
-@lisp
+@*
+@example
 (english-base-ten->number 'six)
-
 @result{} 6
-@end lisp
+@end example
 
-@lisp
+@example
 (apply + (map english-base-ten->number '(one two three four)))
 @result{} 10 
-@end lisp 
+@end example
 
-@cindex pattern variable
-Pattern matchers may contain @dfn{pattern variables}, local bindings
-to all elements that match a pattern.
+@*
+@page
+@cindex pattern variable 
+@noindent Pattern matchers may contain @dfn{pattern variables},
+local bindings to all elements that match a pattern.
 
-@example
-(let re ((ns '(one two three four ten))
-         (total 0)) 
+@example 
+
+(let re ([ns '(one two three four 9)] [total 0]) 
   (match ns
-    ((e) (+ total (english-base-ten->number e)))
-    ((e . es) 
-     (re es (+ total (english-base-ten->number e))))))
-@result{} 20
+    [(e) (+ total (english-base-ten->number e))]
+    [(e . es) 
+     (re es (+ total (english-base-ten->number e)))]))
+
+@result{} 19
 @end example
 
-In this example, the list @var{ns} matches the pattern
+@*
+@noindent In this example, the list @var{ns} matches the pattern
 @code{(e . es)}, where the pattern variable @var{e} corresponds 
-to the `car` of @var{ns} and the pattern variable @var{es}
-corresponds to the `cdr` of @var{ns}.
+to the metaphoical "car" of @var{ns} and the pattern variable @var{es}
+corresponds to the "cdr" of @var{ns}.
 
-A tail call @code{re} is then initiated and we `cdr` down the
+A tail call @code{re} is then initiated and we "cdr" down the
 list by recurring on the tail @var{es}, applying our matcher
 @code{english-base-ten->number} to each element of @var{ns} until
 only a single element @code{(e)} remains, causing the @var{total}
@@ -82,15 +85,16 @@ to be computed.  In modern Scheme programming it is common to use
 of @code{cond}, @code{car} and @code{cdr}, so it's important to
 understand how these idioms translate. 
 
+@*
 Patterns can be composed and nested.  For instance, @code{...}
 (ellipsis) means that the previous pattern may be matched zero or more
 times in a list:
 
 @example
+
 (match lst
-  (((heads tails ...) ...)
-     heads))
-@result{} 
+  (((heads tails ...) ...) heads))
+
 @end example
 
 @noindent
@@ -104,25 +108,31 @@ A pattern matcher can match an object against several patterns and
 extract the elements that make it up. 
 
 @example
+
 (let ((m '((l1 . r1) (l2 . r2) (l3 . r3))))
   (match m
     (((left . right) ...) 
      (list left right)))) 
+
 @result{} ((l1 l2 l3) (r1 r2 r3))
 @end example
 
 @example
+
 (let ((m '((1 . (a . b)) (2 . (c . d)) (3 . (e . f)))))
   (match m
     (((key . (left . right)) ...) 
      (fold-right acons '() key right ))))
+
 @result{} ((1 . b) (2 . d) (3 . f))
 @end example
 
 @example
+
 (match '(((a b c) e f g) 1 2 3)  
   ((((head ...) . rest) tails ...)
    (acons tails head rest )))
+
 @result {} (((1 2 3) a b c) e f g)
 @end example
 
@@ -130,6 +140,7 @@ Patterns can represent any Scheme object: lists, strings, symbols,
 records, etc.
 
 @example
+
 (let re ((m #(a "b" c "d" e "f" g)))
    (match m
      ((or (e) #(e)) e)
@@ -137,7 +148,9 @@ records, etc.
 	   (e1 e2 es ...)) 
        (cons (cons e1 e2)
  	     (re es)))))
+
 @result{} ((a . "b") (c . "d") (e . "f") . g) 
+
 @end example
 
 When a matching pattern is found, an expression associated with the
@@ -145,12 +158,15 @@ pattern is evaluated, optionally with all pattern variables bound to
 the corresponding elements of the object.
 
 @example
+
 (let re ((m '(a b c d e f g h i)))
    (match m
      ((e) e)
      ((e1 e2 es ...) 
       (acons e1 e2 (re es)))))
+
 @result{} ((a . b) (c . d) (e . f) (g . h) . i)
+
 @end example
 
 Compared to hand-written code, pattern matching noticeably improves
@@ -161,7 +177,7 @@ pattern---conversely, hand-written code often trades robustness for
 conciseness.  And of course, @code{match} is a macro, and the code it
 expands to is just as efficient as equivalent hand-written code.
 
-The pattern matcher is defined as follows:
+@noindent @* We define @emph{match} as follows. @*
 
 @deffn {Scheme Syntax} match exp clause1 clause2 @dots{}
 Match object @var{exp} against the patterns in @var{clause1}
@@ -188,7 +204,7 @@ arbitrary Scheme expression, possibly referring to pattern variables of
 @c
 @c clause ::= (pat body) | (pat => exp)
 
-The syntax and interpretation of patterns is as follows:
+@noindent @* The syntax and interpretation of patterns is as follows: @*
 
 @verbatim
         patterns:                       matches:
-- 
2.39.1

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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1145 bytes --]



On 26-01-2023 19:57, Blake Shaw wrote:
> +A pattern matcher does precisely what the name implies: it matches
> +some arbitrary pattern, and returns some result accordingly.

It doesn't need to return anything -- while functional style is common 
in Guile, imperative is still possible.  It can return multiple things 
with 'values'.  I propose replacing 'result' with 'results'.

>   @example
> -(let ((l '(hello (world))))
> -  (match l           ;; <- the input object
> -    (('hello (who))  ;; <- the pattern
> -     who)))          ;; <- the expression evaluated upon matching
> -@result{} world
> +(define (english-base-ten->number name)
> +  (match name
> +    ('zero   0)
> +    ('one    1)
> +    ('two    2)
> +    ('three  3)
> +    ('four   4)
> +    ('five   5)
> +    ('six    6)
> +    ('seven  7)
> +    ('eight  8)
> +    ('nine   9)))
> +
> +(english-base-ten->number 'six)
> +@result{} 6

This is a suboptimal example; this would be better done with 'case'.
I propose replacing it with another example, or adding a note that one 
would normally use 'case' for this.

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[randomlooser]

Il giorno sab, 28/01/2023 alle 14.18 +0100, Maxime Devos ha scritto:
> 
> 
> > +(define (english-base-ten->number name)
> > +  (match name
> > +    ('zero   0)
> > +    ('one    1)
> > +    ('two    2)
> > +    ('three  3)
> > +    ('four   4)
> > +    ('five   5)
> > +    ('six    6)
> > +    ('seven  7)
> > +    ('eight  8)
> > +    ('nine   9)))
> > +
> > +(english-base-ten->number 'six)
> > +@result{} 6
> 
> This is a suboptimal example; this would be better done with 'case'.
> I propose replacing it with another example, or adding a note that
> one 
> would normally use 'case' for this.

The point of this example is not to proficiently program in scheme

It is to introduce possibly naive people to pattern matching
effectively

The aim is to be didactic, there's no implication that this is
idiomatic scheme

I'd pay attention at the curse of knowledge that may be at play, here

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

[randomlooser]

Il giorno sab, 28/01/2023 alle 20.10 +0100, randomlooser@riseup.net ha
scritto:
> Il giorno sab, 28/01/2023 alle 14.18 +0100, Maxime Devos ha scritto:
> > 
> > 
> > > +(define (english-base-ten->number name)
> > > +  (match name
> > > +    ('zero   0)
> > > +    ('one    1)
> > > +    ('two    2)
> > > +    ('three  3)
> > > +    ('four   4)
> > > +    ('five   5)
> > > +    ('six    6)
> > > +    ('seven  7)
> > > +    ('eight  8)
> > > +    ('nine   9)))
> > > +
> > > +(english-base-ten->number 'six)
> > > +@result{} 6
> > 
> > This is a suboptimal example; this would be better done with
> > 'case'.
> > I propose replacing it with another example, or adding a note that
> > one 
> > would normally use 'case' for this.
> 
> The point of this example is not to proficiently program in scheme
> 
> It is to introduce possibly naive people to pattern matching
> effectively
> 
> The aim is to be didactic, there's no implication that this is
> idiomatic scheme
> 
> I'd pay attention at the curse of knowledge that may be at play, here
> 

I just missed the suggestion to add a note

My bad

Adding a note would be perfectly fine

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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1553 bytes --]



On 29-01-2023 03:40, Blake Shaw wrote:
> Hi Maxime,
> 
> Did you watch my talk from Guix days?

I read the text in the talk, but mostly skipped the speech.

> There I detailed that the goal 
> would be to move from what is painfully obvious, gradually building up 
> in chunks and peices. That is what is happening here.

OK, but I don't see the relevance of this information here.

> If you think the 
> progression of examples that follow are suboptimal in comparison to the 
> current state of the documentation, then you should give a reason why as 
> well as offer changes to be made.

I didn't say anything about the progression being good or bad.  I wrote:
>     This is a suboptimal example; this would be better done with 'case'.
>     I propose replacing it with another example, or adding a note that one
>     would normally use 'case' for this.

I.e., the example itself is suboptimal; the progression is presumably good.

Also, I did mention a reason why the example is bad: ‘this would be 
better done with 'case'’.  More explicitly, this example teaches to use 
'match' in situations where 'case' would be a better fit.

And I did offer changes to be made: ‘replace it with another example’
(I don't care which exact example it is replaced with, as long as its a 
simple example to fit in the progression and something where 'match' is 
actually a good fit in order to not teach suboptimal behaviour), and 
also gave an alternative, more explicit change 'add a note'.

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1788 bytes --]



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?

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

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


Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 6862 bytes --]



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.

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

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

?

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.

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

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

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

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

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

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

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.

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[Blake Shaw]

[-- Attachment #1: Type: text/plain, Size: 14916 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 23629 bytes --]

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

[Aleix Conchillo Flaqué]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

Hi!

On Sun, Jan 29, 2023 at 4:50 PM Blake Shaw <blake@sweatshoppe.org> wrote:

>
> 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.
>
>>
>>
First, I apologize for not having gone through all the comments and reviews
or mailing lists messages you guys are discussing. I just wanted to give my
cent (not even two) about the paragraph above.

My interactions with Maxime (mainly through code reviews) have been great.
The biggest review was the one done to merge libevent support into Fibers.
Maxime found the time to review a quite big PR and added a bunch of useful
comments. Reviewing that PR took a lot of effort and I just felt better
after fixing all the comments made. I was even surprised he (I'm assuming
this pronoun) did.

I've always taken code reviews as an opportunity to learn (not suggesting
that you are not, far from that), and whether it's true that Maxime had a
lot of comments (all of them made sense as far as I remember), it's also
true that he is one of the few ones to make code reviews (specially in
Guile). And my feeling is he just wants things to be as correct as
possible, which is quite important, especially in a programming language.

Exchanging messages in a written form has its own challenges (your mood on
that day, maybe you phrase things in a way that can be misunderstood, ...).
So I will stop writing and just leave you all with a smiley face. :-)

Best,

Aleix

[-- Attachment #2: Type: text/html, Size: 3597 bytes --]

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

[Aleix Conchillo Flaqué]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

On Mon, Jan 30, 2023 at 11:56 AM Aleix Conchillo Flaqué <
aconchillo@gmail.com> wrote:

> Hi!
>
> On Sun, Jan 29, 2023 at 4:50 PM Blake Shaw <blake@sweatshoppe.org> wrote:
>
>>
>> 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.
>>
>>>
>>>
> First, I apologize for not having gone through all the comments and
> reviews or mailing lists messages you guys are discussing. I just wanted to
> give my cent (not even two) about the paragraph above.
>
> My interactions with Maxime (mainly through code reviews) have been great.
> The biggest review was the one done to merge libevent support into Fibers.
> Maxime found the time to review a quite big PR and added a bunch of useful
> comments. Reviewing that PR took a lot of effort and I just felt better
> after fixing all the comments made. I was even surprised he (I'm assuming
> this pronoun) did.
>
> I've always taken code reviews as an opportunity to learn (not suggesting
> that you are not, far from that), and whether it's true that Maxime had a
> lot of comments (all of them made sense as far as I remember), it's also
> true that he is one of the few ones to make code reviews (specially in
> Guile). And my feeling is he just wants things to be as correct as
> possible, which is quite important, especially in a programming language.
>
> Exchanging messages in a written form has its own challenges (your mood on
> that day, maybe you phrase things in a way that can be misunderstood, ...).
> So I will stop writing and just leave you all with a smiley face. :-)
>
>

Linking the libevent PR on Fibers in case anyone is curious:
https://github.com/wingo/fibers/pull/53

[-- Attachment #2: Type: text/html, Size: 3850 bytes --]

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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 2602 bytes --]

On 30-01-2023 20:56, Aleix Conchillo Flaqué wrote:
> [...] Maxime found the time to review a quite big PR and added a 
> bunch of useful comments. Reviewing that PR took a lot of effort and I 
> just felt better after fixing all the comments made. I was even 
> surprised he (I'm assuming this pronoun) did.

Unfortunately you are assuming incorrectly; s/he/she/. (*)
For future reference, 'they' is usually a safe ‘default’ (except when 
they hate that, eergh).  At least, for some values of 'usual' that might 
not be representative.

> [...] And my feeling is she just wants things to 
> be as correct as possible, which is quite important, especially in a 
> programming language.

That's it, yes.

> Exchanging messages in a written form has its own challenges (your mood 
> on that day, maybe you phrase things in a way that can be misunderstood, 
> ...). So I will stop writing and just leave you all with a smiley face. :-)
> 
> Best,

Something I would like to add here, is that these kind of emotional 
challenges often appear self-inflicted to me.  I mean, the mailing list 
is a rather technical medium for technical talk about technical things. 
There is no emotional stuff there unless you add it or you assume it.

Instead of analysing technical messages on the ML for whether there's 
some emotional hidden message behind it, can't we just assume that any 
technical messages are just technical, meaning literally what's written 
in them?

I'm not saying that the emotional stuff should be completely forbidden, 
but like, with a little care you can separate the technical from the 
emotional, e.g.:

    ‘[Oh, I wanted that feature for a long time!]

     This won't work at all because it assumes frobs are never barzed,
     yet they are when [...].  I'm thinking you'll need a completely
     different approach, though I don't have a clue what this approach
     would be.

     [Keep up the good work!]’

(The [...] lines are nice, but optional.  Also the brackets are 
optional.).  Like, the second paragraph just says it won't work at all 
because $reasons.  While very unfortunate, there is no malice anywhere; 
it's just technical stuff.  Likewise, the first [...] and last [...], 
while emotionally positive, are irrelevant for the evaluation of the 
technical middle part.

> Aleix
> 

(*) There are people who apologise after making such mistaken 
assumptions, which I suppose is a quite reasonable course of action to 
take in general, but please don't in this case?  It just seems 
embarrassing to me.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[Aleix Conchillo Flaqué]

[-- Attachment #1: Type: text/plain, Size: 3414 bytes --]

On Mon, Jan 30, 2023 at 6:53 PM Maxime Devos <maximedevos@telenet.be> wrote:

> On 30-01-2023 20:56, Aleix Conchillo Flaqué wrote:
> > [...] Maxime found the time to review a quite big PR and added a
> > bunch of useful comments. Reviewing that PR took a lot of effort and I
> > just felt better after fixing all the comments made. I was even
> > surprised he (I'm assuming this pronoun) did.
>
> Unfortunately you are assuming incorrectly; s/he/she/. (*)
> For future reference, 'they' is usually a safe ‘default’ (except when
> they hate that, eergh).  At least, for some values of 'usual' that might
> not be representative.
>
>
Oh, well. I confess I did a quick Google search but I clearly assumed
incorrectly based on the results, my bad. I don't hate using they at all.

> [...] And my feeling is she just wants things to
> > be as correct as possible, which is quite important, especially in a
> > programming language.
>
> That's it, yes.
>
> > Exchanging messages in a written form has its own challenges (your mood
> > on that day, maybe you phrase things in a way that can be misunderstood,
> > ...). So I will stop writing and just leave you all with a smiley face.
> :-)
> >
> > Best,
>
> Something I would like to add here, is that these kind of emotional
> challenges often appear self-inflicted to me.  I mean, the mailing list
> is a rather technical medium for technical talk about technical things.
> There is no emotional stuff there unless you add it or you assume it.
>
> Instead of analysing technical messages on the ML for whether there's
> some emotional hidden message behind it, can't we just assume that any
> technical messages are just technical, meaning literally what's written
> in them?
>
>
That's how I see it too and that would be ideal.


> I'm not saying that the emotional stuff should be completely forbidden,
> but like, with a little care you can separate the technical from the
> emotional, e.g.:
>
>     ‘[Oh, I wanted that feature for a long time!]
>
>      This won't work at all because it assumes frobs are never barzed,
>      yet they are when [...].  I'm thinking you'll need a completely
>      different approach, though I don't have a clue what this approach
>      would be.
>
>      [Keep up the good work!]’
>
> (The [...] lines are nice, but optional.  Also the brackets are
> optional.).  Like, the second paragraph just says it won't work at all
> because $reasons.  While very unfortunate, there is no malice anywhere;
> it's just technical stuff.  Likewise, the first [...] and last [...],
> while emotionally positive, are irrelevant for the evaluation of the
> technical middle part.
>
>
Again, that's how I try to approach it as well. And actually I believe I
tend to be emotional by adding positive messages as the ones you just
mentioned. Even though they are irrelevant I like to think people like to
read nice things after all (at least, I do).


> > Aleix
> >
>
> (*) There are people who apologise after making such mistaken
> assumptions, which I suppose is a quite reasonable course of action to
> take in general, but please don't in this case?  It just seems
> embarrassing to me.
>

Since you made it optional with ?... I apologize. I don't mind
embarrassing myself (and I hope I don't embarrass you).

Best and keep up the good work!

Aleix

[-- Attachment #2: Type: text/html, Size: 5479 bytes --]

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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 45276 bytes --]

On 30-01-2023 01:49, Blake Shaw wrote:
> 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

It is not.

> over what is ultimately 
> minutiae (I'll get into specifics momentarily)

They are, and details are nice to get correct too.  You are missing a a 
few step from 'there remains a few minutiae to fix' to 'gatekeeping'.

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

Likewise-ish for me, with different causes -- at various times in the 
past, people have made false accusations against me on the Guix ML 
(three times, IIRC) -- at least three times during patch review, the 
first time in review of a ZFS patch by some outsider that completely 
ignored previous discussion to state (not argue with reasonable 
arguments, but just state their position and quote arguments that were 
already refuted) their disagreement, the second time was a case of 
miscommunication in retrospect but still false accusation, and the third 
time by someone who isn't literally a maintainer but in practice pretty 
close to it.

(The last is in-progress with the Guix CoC so I will not go into any 
detail.)

As such, I hope you understand I'm annoyed I have a fourth to add to the 
tally.

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

This sounds like Guix CoC stuff, take it up with 
guix-maintainers@gnu.org as per the first paragraph of the CoC.  Also, I 
didn't ignore you, in 
<https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00074.html> I 
went through the unadapted proposals and explained why I didn't adapt 
them (mostly because they made things worse).  This is all I'm going to 
say here about Guix things on this Guile ML.

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

Again, Guix CoC stuff.  Now onto Guile (which doesn't have a CoC with a 
guix-maintainers equivalent) stuff ...

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

Please follow your on demand for 'consider ... the literal meaning of 
words I employed'.  'Presumably better' literally just means that, 
presumably better.  I _did_ look at the series of examples, and the 
series appeared reasonable, and I guess better than what we had before, 
hence I wrote 'presumably better'.

I could, in theory, have written 'better' without the qualifier, but 
that would have been dishonest because I do not understand the impact of 
these kind of style changes well enough.

As such, I went for the neutral 'presumably better', as a kind of 
'presumably innocent of proven guilty' thing.

Also, at no point did I shoot down the contribution -- I didn't even 
reject the contribution; I only had some minutiae to comment on, which 
meant that the patch was almost done -- you only had to address a few 
tiny things and then the patch would probably be accepted by Guile 
maintainers.  And given that they were mostly minutiae, it is likely you 
could just have said 'Wording isn't ideal, but it's better than what we 
had before and I don't know how to make it perfect.’ and that would then 
have been it.

It's like, a review with just some minutiae and bikeshedding means that 
the reviewer thinks it's a good patch.

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

Again Guix CoC stuff.

> And there's more, its a pattern; I dont know if you troll everyone like 
> this

I don't troll anyone, especially not during serious matters such as 
patch review.  (I occasionally 'poked some fun' on #guix, but not 
trolling and especially not trolling during serious matters.)

> or if I represent something you feel opposed to,

I'm opposed to how you are equating 'the reviewer only had some minutiae
to comment on and doesn't have anything (neither good nor bad) to say
about this cool structure I'm fond of' with 'the reviewer is malicious, 
gatekeeping troll that ignores me'.

I'm also opposed your hypocrisy -- you ask to consider the literal 
meaning of words that were employed, but you didn't do that for the 
'presumably better'.

I'm also opposed how you keep resorting to the 'argument from authority' 
fallacy, and how you keep maintaining the authority as correct even when 
provided evidence that the authority is wrong.  (More about the 
'authority' stuff later ...)

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

Yes, except for 'admit -> state'.  'Admitting' would mean that I did 
something wrong here, or that I in the past claimed the contrary.

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

Agreed.

> whether or not you said **aside from inlining**.

Agreed, and irrelevant, because inlining is sufficient to run the example.

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

Agreed, but like, inlining would have sufficed.

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

Actually run the code I provided, please -- if you copy-paste it into a 
Guile REPL, you'll get a result that doesn't contain any mention of 
'unquote-splicing':

(match '((x) (y y0) (z z1 z2))
   (((heads tails ...) ...)
    heads))

;; -> (x y z)

> 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)..
The original example, before your change, did not include any 
quasiquotation / unquotation -- there is no mention of ',@' anywhere in 
this code:

 > - (match lst
 > -  (((heads tails ...) ...)
 > -   heads))

I.e., the quasiquotation code was added by you.  At no point did I 
propose adding examples that do quasiquotation, and at no point did I 
propose reverting to old examples with quasiquotation.  Rather, I was 
wondering why you _added_ quasiquotation:

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

If you think the quasiquote stuff is wrong, why add them if the original 
code didn't do quasiquote stuff, and why complain to me about the code 
you wrote?

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

See my previous response.  Also, I did read the example, and it seemed a 
nice example to me.  'Subtle', 'important' and 'comprehend' are quite 
vague and subjective, so I won't comment on that.

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

If you post a draft to the ML, it's the draft I'll review.
To get a review on your final version, send it as a v2 patch series and 
remember to squash commits.

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

My brain doesn't have git installed for autosquashing and rebasing.
When I review, I just review patches one-by-one -- look at patch 1 in my 
e-mail program, determine if it 'seems right', send review. Look at 
patch 2, look if it 'seems right', etc..  This is a mostly stateless 
process -- while I'll remember that 'patch 1 added lots to match 
documentation' when reviewing patch 2, I do not recall that 'this 
changed example wasn't present in the original Guile documentation but 
rather was an example from the first patch' -- it's a rather lossy 
compression; I made the standard assumption that you would have squashed 
the commit if it was just a fix to the previous commit.

I only now see that your 2/6 commit modifies an example from the 1/6 
commit -- there are no chips or shoulders involved.  You could just have 
responded at the beginning 'This is a mistake I made in the first patch 
that's amended by the second patch; this change should make more sense 
if you consider the first two patches together.'.

Looking at your responses again, it turns out you did write something 
like that:

 > Thanks! The new latest edit is still preferred but I'll keep that in
 > mind for the future.
 > [...]
 > Because the result in the final commit is better. Sorry, I should have
 > added this commit to fixup when I was rebasing.

... but to me that read like ‘I'll send a v2 patch series later where 
the second patch is replaced by a patch replacing the unescaped @ by the 
escaped @@’.

Also, it's the patch sender's responsibility to squash commits within a 
patch series where appropriate, not the reviewers.

There is also no 'pattern recurred at the first sight of my return' --
I apply the same reviewing routine (*) to everyone, this isn't something 
you specific. (*) I.e.: mostly statelessly review patches one-by-one, 
assume that the patch sender squashed things where appropriate, assume 
that with 'final commit is better ... stuff about fixups' they mean they 
will send a v2 patch series.

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

I did look at this, and the lesson is unclear.

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

I didn't notice it rotates things, I thought it was just some arbitrary 
relatively simple 'match' example that still had some complexity with 
'...' and quasiquote / unquote / unquote-splicing.

For people who aren't as good at, err, [pattern matching pattern 
matchers and assigning meanings to pattern match patterns] as you,
I recommend actually stating what this example does, even if it's just 
an imprecise ';; rotate lists'.

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

Then, you know, autosquash it before sending.

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

This response:

    (1) while it is relevant to the second paragraph, this still does not
        answer my request on what the change is for.

    (2) it is indented on the same level as my text you quoted,
        and my text didn't have '>' markers, so I glossed over this
        at first.  For the future, I recommend picking a single quotation
        style and sticking with it within a single e-mail, to aid reader
        comprehension -- the ‘<b>:’ marker is fine I suppose, but only
        if you use it consistently.

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

This is another instance of hypocrisy -- this is just arguing, which you 
were negative about:

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

If you want to go arguing about irrelevant tangents (I already agreed 
that my original claim was kinda wrong with 'OK, terminology 
difference'), that's fine; myself I do love going on tangents, but 
please don't be hypocritical about it.

Ordinarily I wouldn't mind continuing this tangent by speculating on 
where our difference in terminology for 'semantics' and 'terminology' 
comes from and how we therefore are both wrong or right, depending on 
what exact meaning is ascribed to 'semantics' and 'terminology' (these 
terms have multiple meanings after all ...), but given the circumstances 
I'm not in the mood for it at all.

(I guess something about differences in backgrounds in linguistics (*) 
and mathematics & compsci; in the latter 'terminology' can mean the 
mapping of words to mathematical concepts (more precisely, mapping from 
words to formulae representing some various kinds of objects, assuming 
that the mathematical concepts have solid foundations)) and semantics 
could be assigning a 'meaning' to these mathematical objects (not their 
names, but the objects (or formulae) theirselves), in some informal 
sense or with something like denotational semantics, ...)

(*) Looking further in the e-mail, it's actually philosophy? Huh.

(I know I said I'm not in the mood for it, but my thought process 
continued on anyway, so I posted the start of it here to get it out of 
my mind.)

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

This I disagree with, see later.

> Left names a 
> pattern that binds to the list of all left associations, right binds a 
> list of all of the right associations.

Agreed, except for casing (Scheme is case-sensitive, Left != left), with 
the caveat that 'Left names a pattern -> @var{left} is a pattern 
variable' would be more specific and more to the point.

> A pattern = a sequence of 
> locations; its the sequence a generic pattern variable "represents".

That's certainly _a_ definition of pattern, but this isn't the meaning 
that SRFI-204 ascribed to patterns.  Where are you getting this 
non-standard definition from?

E.g., in the introduction it states:

   Patterns are written to look like the printed representation of the
   objects they match. The basic usage is (match expr (pat body ...)
   ...) where the result of expr is matched against each pattern in turn,
    and the corresponding body is evaluated for the first to succeed.
   Thus, a list of three elements matches a list of three elements.

   (let ((ls (list 1 2 3)))
     (match ls
       ((1 2 3) #t)))

   => #t

 From (match expr (pat body ...) ...) and "where the result of expr is 
matched against each pattern in turn", it is clear that the stuff on the 
left of body is called a 'pattern' -- the combination (pat body ...) is 
called a clause, but the 'pat' is a pattern.

Furthermore, the document states:

   [...] The following terms will be used in describing pattern matching:

   pattern
       data that is supposed to match against the first argument to the
       match form.

-- there is no mention of 'sequences', 'locations', or 'variables' here.

In fact, there is not a single mention of 'location' or 'sequence' in 
SRFI-204.  Neither is there any mention of 'location' in 'A Practical 
Soft Type System for Scheme' (where 'match' originated from).  (There is 
a mention of sequences, but only as part of the combination 'reduction 
sequences', which doesn't appear to have anything to do with 'match'.

More to the point, let's return to ‘However, there is no 'or', 'and' or 
multiple clauses [...]’ and how I'm not conflation patterns with pattern 
clauses there.

In the section 'Ellipses and Tail Patterns', there is:

   An ellipsis will match any number (zero or more) of a pattern (like a
   regex Kleene star):

.  This implies that, according to SRFI-204, at least some patterns 
consist of smaller patterns (not pattern clauses consisting of multiple 
patterns or such, but literally patterns consisting of patterns).

Furthermore, the documentation for 'or' even drops the word 'subpattern' 
and talks about matching an object against subpatterns:

    The or operator ensures that at least one subpattern matches. If the
    same identifier occurs in different subpatterns, it is matched
    independently. All identifiers from all subpatterns are bound if the
    or operator matches, but the binding is only defined for identifiers
    from the subpattern which matched.

    (match 1 ((or) #t) (else #f)) => #f

    (match 1 ((or x) x)) => 1

    (match 1 ((or x 2) x)) => 1

I haven't checked but I would assume the same holds for the 'and' 
combination and something similar for 'not'.

For another perspective, the SRFI has the following text:

   A pattern can have one of the following forms:

   <pattern> -> (<pattern> ...) |
               #(<pattern> ...) |
                  <pattern identifier> |
                  <pattern s-expression> |
                  <tail pattern> |
                  <ellipsis pattern> |
                  <record pattern> |
                  <getter or setter pattern> |
                  <field pattern> |
                  <predicate pattern> |
                  <boolean pattern> |
                  <tree pattern> |
                  <quasi-quote pattern> |
                  _

What I'm seeing here, is that a pattern can consists of smaller patterns 
  (and not necessarily a sequence (^) of 'locations', whatever that 
would mean in this context (*) -- while a list (<pattern> ...) of 
smaller stuff <pattern> is possible, it could instead be a predicate 
pattern, or a vector #(<pattern> ...)).  By the 'not necessarily', this 
contradicts your definition ‘A pattern = a sequence of locations’.

(^) As 'sequence' is nowhere defined in the SRFI, I will assume you 
meant 'list'.
(*) I'd guess you mean location=pattern variable but that seems 
contradicted by some of your statements so I dunno.

Hence, I believe I have solid evidence that patterns can, in fact, 
consist of smaller patterns, and given the 'or' and 'and', I have solid 
evidence that sometimes a single object is matched against several 
(sub)patterns.

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

Yes?  I'm not disagreeing with any of this.  I also at no point stated 
anything about data types.

> A pattern clause is a sequence of pattern variable.

What?  No.  If you insist on this, quote your sources -- provide a 
citation of the relevant part of SRFI-204 or 'A Practical Soft Type 
System for Scheme'.  Later in your e-mail you start talking about how 
you did a PhD and published in international papers, so you should 
already know that you must quote your sources and why quoting your 
sources is important.

Looking at the SRFI, a 'pattern clause' is defined as:

   pattern clause
     a pattern and its body.

For example, in (match obj (() "it's empty") (#f "it's false")), there 
would then be two clauses: (() "it's empty") and (#f "it's false").

The first pattern clause (() "it's empty") is a sequence consisting of 
() and "it's empty", neither of which is a pattern variable (the former 
is a pattern, yes, but not a variable and not a pattern variable). 
Likewise for the other pattern clause.

This directly contradicts your definition 'a pattern clause is a 
sequence of pattern variables'.

>     Proposal: 'several patterns -> a pattern' (which happens to consist of
>     smaller patterns).
> 
> 
>     ~ Why?

I already explained this; it's because the old sentence is kind of 
misleading, because in the example that follows the object is only 
matched against a single pattern, not several (except in the degenerate 
sense 'several = 1', but ergh).  (There of course also exist alternative 
solutions, like adding more clauses to the match example such that 
objects are matched against multiple patterns, or adding a note that 
while in this example the object is only matched against a single 
pattern, there will be examples on how objects can also be matched 
against multiple patterns later).

Quoting my previous reply, where I already explained the reason:

>     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))). 
[ end of quote ]

> If we start mixing and matching
> 
>     ~  all these subtly different terms

(1) I'm ignoring these ~, dunno what's up with those.

(2) I'm not proposing mixing any terms.  My proposed change was, I 
repeat, 'several patterns -> a pattern'.  There are only three terms 
here: 'several', 'pattern' and 'a'.  The 'a' doesn't count because it's 
just an article.  There are then only two remaining terms 'several' and 
'pattern', and the change then consists of _removing_ a single term.

How is removing a term and doing nothing else, a case of 'mixing and 
matching'?  If nothing else, as only a single term remains, it's 
impossible for there to be 'different terms', as there is only, you 
know, a single term, so there is no difference between two 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

In my proposal of 'several patterns -> a pattern' and its rationale, at 
no point did I start talking about vibes.  Hence, err, non-sequitur? 
Instead of talking about vibes and subtlety, could you make your point 
directly without any of this vague talk about vibes & stuff?

It's just code and code documentation, this stuff can, and should, be 
done without the emotion stuff and vagueness.  More explicitly, stop it 
with the vague vibe talk, please.

>      >
>      >      > +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>
>      >     <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 thought I made my point clearly. Going by your 'Huh?' response, it 
appears I was unsuccessful. While unfortunate, it is acceptable to not 
understand what the other party is talking about. However, just stating 
that you don't understand without making any indication on _what_ part 
of it you don't understand, is completely unproductive.

More to the point, you will have to elaborate on what part of my 
explanation you aren't following; I'm not a mind reader.

Alternatively, perhaps this is you saying that you disagree with what I 
wrote, but then you will have to be more explicit on what parts you 
disagree -- again, not a mind reader.

>      >
>      >
>      > 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, and the source I quoted, previously explained what the two dots are 
for -- while I did not use the term 'nonsense', the source and I did 
explain how the dots are useful and sensible (hence, not nonsense).

Even if you dislike the duplication of the dots more than the benefits 
the dots bring, this does not make the dots 'non-understandable' or 
'nonsense'.  I mean, even if someone thought it was a grammar error (or 
a typography error, if you are one of the people that keep typography 
separate from other grammar), double dots are, in fact, readable.

I mean, you can read and understand the following sentence, right?:

   "She explained the rules for periods, commas, semicolons, etc.."

You are again just repeating your claim that the double periods are 
bogus instead of actually providing new evidence; it's becoming an 
'argumentum ad infinitum'.

Going by your mention of a PhD with Alain Badiou, you appear to have 
done studies in philosophy.  While I'm not familiar with the exact 
composition of philosophy programs, I would assume you had a course 
about logic and proper argumentation structures, please use it.

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

Ok, though I don't care about 'boring' and 'normality'.  Normality is 
overrated.

> because 
> collectively authored documentation is something you should never adopt 
> non-standard writing notation in the course of authoring,

Finally, you now give an actual new argument that isn't a fallacy.
While the 'never' seems too strong to me (I did propose adopting a 
non-standard notation after all ...), this is actually a valid argument! 
You could have made this argument at the beginning instead of keeping 
hammering on authority and stating my position was just nonsense.

> just to one up someone on a mailing list.

Agreed.  You are also assuming things that aren't true here.  I didn't 
do things 'to one up someone'.  Also, it being on a mailing list is 
irrelevant.

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

If 'this kind of attitude' = 'one-upping' -- not relevant here, see 
previous response.

If 'this kind of attitude' = 'adopting non-standard notation': adopting 
non-standard notation is compatible with stylistic consistency and 
editors -- if you do the "don't merge the dots" consistently throughout 
all the documentation, the result will be, well, stylistically consistent.

> I'm just saying be should use sensible standard punctuation,

'Use sensible punctuation' sounds sensible to me, that's why I proposed 
changing the IMO nonsensical standard "merge the dots" with the sensical 
non-standard "don't merge dots".

I gave an argument for why the standard is nonsensible and why the 
nonstandard is sensible; I'm still waiting for your argument on the 
opposite.  (Sensible is not always standard, and conversely.)

I already read your claim plenty of times and in different forms, your 
position is quite clear to me, I'm just waiting for any actual 
_arguments_ for your position.  Again, please use your philosophy education.

> [...] when 
> someone says "i want to use this that would

This sentence is unparsable, you'll need to retransmit it.

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

I already gave a reason for this change; it's even (in abbreviated form) 
in the paragraph you just quoted: ‘but ... This is like the example at 
with a link to a document that explains in some detail the reasoning 
behind it.’.

I do not appreciate your claim that I gave no reasons when I literally 
gave, er, reasons; especially when as evidence that I supposedly gave no 
reasons, you quote a paragraph where I just gave the reason!  Your 
'evidence' actually disproves your claim.  Again, please use whatever 
logic and argumentation course you have had; you are decreasing my 
respect for academic philosophy.

More explicitly, the change is to benefit reader comprehension.  This is 
explained in the source I quoted.  Please read it, instead of assuming 
that the changes I propose are obviously some malicious plot (*), and do 
not claim I gave no reason. Likewise, if you didn't did actually read it 
but didn't get the point, you could just ask for elaboration instead of 
talking about malicious plots (*).

(*) While you did not use the words 'malicious plot', your paragraph 
pretty much claimed I performed a specific kind of malicious plot.

Also, the 'bizarre grips you hope to keep the documentation locked in' 
is incorrect. It needs to be replaced by 'unconventional proposals for 
improving the documentation'. (Perhaps the proposals are wrong, or the 
concerns in the rationale of the proposal are excessive; to be 
absolutely clear I'm not stating you are required to believe the 
proposals are correct.)

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

Again, you can't counter an argument by authority by another argument by 
authority. You need to give _actual arguments_.  Given your lackluster 
argumentation so far, your claimed authority is completely unconvincing 
to me.  Instead, given your lackluster argumentation on guile-devel, by 
invoking authority (PhD, Alain Badious, teaching, publishing in 
international journals), you aren't raising my opinion of your 
argumentation (*), but rather you are lowering my opinion on the PhD 
system, Alain Badious, your institution, international journals about 
philosophy and the academic field of philosophy.

(*) More precisely, the lack thereof.

You are not required to be immediately 100% competent at things; it is 
fine to learn over time, but your insistence on 'I'm right because 
authority even when I receive evidence that the authority is wrong' 
isn't doing you any favours -- revising common consensus because of new 
evidence is basic science stuff; authority is irrelevant (except for law 
stuff, but that's not the case here).

To be 100% explicit, as you keep going on about authority -- when 
someone sends a patch on the mailing list, I do not care about 
authority.  I don't care what accreditations they have obtained.
I do not care about their titles (bachelor, master, PhD, professor, 
rector, whatever).  I do not care what supervisors they have had.  I do 
not care if they published any papers.  I do not care what people they 
have met.  I do not care how much life experience they have had or their 
age -- if a baby writes a good patch, I would accept that patch, if some 
old wise and experienced person writes nonsense, their nonsense would be 
rejected.  I do not care about their positions -- the Chief GNUisance 
and the Guile maintainers would not obtain any exceptions by their 
positions.  I also don't care about 'Christ's sake'.

In short, I do not care about any such thing, because they are 
ultimately irrelevant -- it is not the position or diploma that matters, 
but rather the knowledge and skills that someone in a position or in 
possession of a diploma is supposed to have.  A position, diploma, PhD 
title, etc., is a sign of knowledge and skill, but does not imply 
knowledge or skills, and knowledge and skills can be obtained without 
corresponding positions or titles.

What I care about, is good patches and clear communications, and that's 
about it.

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

(That sentence is ungrammatical, so I might have misinterpreted it below.)

You state the MLA and anything else says that merged periods aren't a 
real thing because merged periods aren't a real thing.

This contradicts your example extracted from the MLA, which states that 
periods should be merged (not in those words, but still), so 'merged 
periods' appear to really exist in practice (even if not what I'd 
recommend, merged periods definitely exist. Example: "Eat fruit, sugar, 
etc.").

As such, I assume you meant:

‘Nobody at MLA, or any other style guide, ever said that merging periods 
is good, because unmerged periods aren't a real thing.’

This is false, because: unmerged periods _are_ a real thing.  Here's an 
example:

    "She explained the rules for periods, commas, semicolons, etc.."

Are you denying that I wrote two periods next to each other, and hence 
denying that unmerged periods exist -- in other words, that unmerged 
periods aren't a real thing?  Are you denying that unmerged periods 
exist in the source I gave you?

I suppose you could deny that, but you'd need some "reality is fake 
because it's a simulation" philosophy or 'your e-mail and that site was 
hacked; someone edited that page and the e-mail to merge the dots'  for 
that, and the former situation is irrelevant to Guile development and 
the latter situation is not something I can help you with.

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

I again claim that nothing I said has been nonsense -- maybe positions 
you disagreed with, maybe ultimately what I claimed was wrong, but all 
this 'nonsense' you speak of has an explanation, and hence isn't 
'nonsense' and is at worst merely incorrect.

Also, I have likewise-ish sentiment -- I do not want to deal with your 
'but authority; your relevant evidence is bogus because it contradicts 
authority' nonsense.

No.  You don't get to opt-out of patch review.  Nobody gets an exception 
on patch review.  That would defeat the point of patch review.

   * Disagreeing with a patch review is fine; just don't resort to
     personal attacks and such, and try to articulate your position
     and reasoning clearly.  In particular, don't go insinuating that
     that the reviewer is doing some malicious gatekeeping trolling plot,
     and don't commit fallacies like 'authority authority authority!'.

     Whether your patch that does not implement
     some of the proposed changes, is actually merged without those
     changes, will be up to the maintainers.

   * Just sending patches and ignoring all patch review is ...
     suboptimal, but acceptable as long as you do not insist on them
     actually being merged in their unedited state; contributions are
     contributions.

   * If for whatever reason you can't stand a certain reviewer, I suppose
     you could ignore them. However, At the same time, the reviewer might
     have some important points, so it's quite likely that the Guile
     maintainer 'on duty' will say something like 'Why isn't this point
     by reviewer Foo addressed?  It seems reasonable to me.’.  You would
     then have to actually read the review, or ignore the maintainer,
     and the latter will not result in your patch being merged.

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]