[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 + CoC

From: Maxime Devos
Subject: Re: [PATCH v1 1/6] docs/match: add pattern matching examples + CoC
Date: Tue, 31 Jan 2023 03:28:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0

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

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 as per the first paragraph of the CoC. Also, I didn't ignore you, in <> 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 < <>> 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
     > 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,


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

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

     > 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
    have ,@ and 'head' have ',', instead of both having ',@' or both
    having ','?

    What I'm missing is, why did you change

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


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


1st, an aside: none of this actually matters. These come from commits at the beginning of the patch set. This was first draft. The final examples i proposed for the docs are much nicer.

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

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
     > See SRFI-204 on the Shinn Pattern matcher which (ice-9 match)
    more or
     > less implements
     > <

OK, terminology difference.

No, this is a precise semantic difference.

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

      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,
     >      > +records, etc.
     >     Missing end-of-sentence period. The . in 'etc.' is part of the
     >     abbreviation 'etc.', not an end-of-sentence marker.  I know it's
     >     'standard' English (for some value of 'standard' in English) to
     >     conflate
     >     all the dots, but we don't have to follow standard when they
    are buggy.
     >     (This is like the example at
     >     <
     >     <
    <>>> about not moving the
     >     end-of-sentence period inside quotation marks:
     >           Then delete a line from the file by typing “dd”.
     >           Then delete a line from the file by typing “dd.”
     >     -- while in this particular case (i.e., 'etc.') the
    distinction is
     >     unimportant, for consistency with other cases where the
    distinction is
     >     important, I would go for '..., symbols, records, etc..'.


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


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

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


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]