[Top][All Lists]

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

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

From: Maxime Devos
Subject: Re: [PATCH v1 1/6] docs/match: add pattern matching examples
Date: Sun, 29 Jan 2023 16:30:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0

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

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

Aside from the inlining, it absolutely isn't clear. Aside from the inlining, your new example is less clear to me -- e.g., why does 'tails' have ,@ and 'head' have ',', instead of both having ',@' or both having ','?

What I'm missing is, why did you change

  (((heads tails ...) ...)


  (((head ...) tails ...)
   `(,@tails ,head)))


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

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
    all the dots, but we don't have to follow standard when they are buggy.

    (This is like the example at
    <>> about not moving the
    end-of-sentence period inside quotation marks:

          Then delete a line from the file by typing “dd”.

          Then delete a line from the file by typing “dd.”

    -- while in this particular case (i.e., 'etc.') the distinction is
    unimportant, for consistency with other cases where the distinction is
    important, I would go for '..., symbols, records, etc..'.

I'm sorry but again, this is simply bad style and incorrect suggestions. According to the MLA, the authority on English style:

It appears to be _an_ authority, but certainly not _the_ authority.
I believe it's common knowledge there is no central authority on English.

"A sentence should never have two periods at the end. If a sentence ends with an abbreviation followed by a period, do not add an additional period:

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

Thats MLA's example of the correct way of how to end a sentence with punctuated abbreviation.

It appears you disagree that dots shouldn't be merged, but you aren't giving a proper argument for your position or a counter-argument to my argument -- with your reference to MLA, you were making an appeal to authority, which on its own is an argument, but:

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


Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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