[Top][All Lists]

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

Re: Replace trivial pcase occurrences in the Emacs sources

From: Michael Heerdegen
Subject: Re: Replace trivial pcase occurrences in the Emacs sources
Date: Tue, 06 Nov 2018 01:00:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> > > Destructuring binding requires destructuring, that's all.
> > 
> > "Destructuring binding" - pcase has nothing like that.
> The section in question is not about pcase, it's about pcase-let,
> pcase-let*, and pcase-dolist.

I only summarized these as `pcase' since they use the same pattern
matching mechanism from pcase.

> Would you be happier if the text said "typically" instead of
> "generally"?  Because that's what it means.

It's ok for me if it means that.

> Could you please tell what concrete changes in the doc strings of
> pcase-let etc. would make you happier?  I feel that we are trapped in
> abstract discussions with no clear way out, and I think I'm at least
> slightly confused what is it that you don't like about the current
> docs.

I'm also confused.

I found the old docstrings simple and clear (though they lacked some
details).  I find already reading the new docstrings in order to make
suggestions for improvements straining.

After I read your response, I see and can comprehend now that everything
makes sense from your point of view.  You have a totally different view
and understanding than I.  For example, for you

  `(,a ,b)


  `[,a ,b]

are two different patterns for destructuring binding that can be used in

For me, I see SYMBOL as the trivial pattern thing to establish bindings,
and the ` macro which has a simple specification that fits into very few
lines, and above we have two examples of combining and using the two.

I can only say that I find the new docstrings more confusing and
complicated than before, and I find it a mistake to describe the
behavior using concepts like "destructuring binding" that neither have a
direct counterpart in the implementation nor in the specification.  I
agree it could help people when the manual uses such concepts to explain
things and make nice chapters, but I don't like it when docstrings use
such terms, terms that are not clearly defined and don't really fit to
how the thing actually works, instead of giving a clear description.  I
understand now that the new docstrings actually give a clear description
to you; for me, they are now harder to read and understand.

So I don't think I can be of much help, becauseprobably my suggestions
would not be acceptable for you.  I wonder if there is still a way to
provide the old docstrings, at least as comments in the sources?



reply via email to

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