[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)
and
`[,a ,b]
are two different patterns for destructuring binding that can be used in
pcase.
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?
Thanks,
Michael.
- Re: Replace trivial pcase occurrences in the Emacs sources, (continued)
- Re: Replace trivial pcase occurrences in the Emacs sources, Eli Zaretskii, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Eli Zaretskii, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Eli Zaretskii, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Michael Heerdegen, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Eli Zaretskii, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Michael Heerdegen, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Eli Zaretskii, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Michael Heerdegen, 2018/11/03
- Re: Replace trivial pcase occurrences in the Emacs sources, Eli Zaretskii, 2018/11/04
- Re: Replace trivial pcase occurrences in the Emacs sources,
Michael Heerdegen <=
- Re: Replace trivial pcase occurrences in the Emacs sources, Eli Zaretskii, 2018/11/05
Re: Replace trivial pcase occurrences in the Emacs sources, Michael Heerdegen, 2018/11/04