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

[Maxime Devos]

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.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature