[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Instead of pcase
From: |
Michael Heerdegen |
Subject: |
Re: Instead of pcase |
Date: |
Sun, 19 Nov 2023 15:14:58 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
> > What I don't like here in this discussion is that some people are not
> > willing to accept that other people make different experiences with the
> > same things.
>
> This goes both ways, you know.
Indeed.
I'm curious how an alternative could look like, actually. But unless
such an alternative exists or is completely designed, it is only a claim
that it would lead to less mistakes and would be simpler. And I doubt
it.
It would have to implement the same set of features, so it would be
quite as complex as `pcase'. You would have to remember or look up more
or less the same things and details. Maybe in a different mood (some
people less angry, others more).
And here the `rx' example and `pcase' are very similar: what the
programmer actually has to keep in mind is how the regexp matching
algorithm or the pattern matching algorithm works. This part is still a
black box, you must learn the specification, independently from the
language used to specify the matchers. How the result is interpreted is
always something you have to learn additionally.
In your example, actually, string regexps are the primitive, low level
language, `rx' is the higher level language, so it should lead to less
mistakes (your argument). `pcase' is the extensible higher level
language for pattern matching, specifically designed for this purpose,
so it should be more suited and lead to less mistakes than more
primitive tools.
Has anyone counted how many mistakes were introduced by wrong pcase
pattern specifications, compared to more verbose re-formulations using
other tools? If we don't do that, the discussion is still selective,
with other words, about preferences again.
Michael.
- Re: Instead of pcase, (continued)
- Re: Instead of pcase, Eli Zaretskii, 2023/11/19
- Re: Instead of pcase, Dmitry Gutov, 2023/11/19
- Re: Instead of pcase, Eli Zaretskii, 2023/11/19
- Re: Instead of pcase, Dmitry Gutov, 2023/11/19
- Re: Instead of pcase, Eli Zaretskii, 2023/11/19
- Re: Instead of pcase, Dmitry Gutov, 2023/11/19
- Re: Instead of pcase, Eli Zaretskii, 2023/11/19
- Re: Instead of pcase, Richard Stallman, 2023/11/20
- Re: Instead of pcase,
Michael Heerdegen <=
- Re: Instead of pcase, Eli Zaretskii, 2023/11/19
- Re: Instead of pcase, Michael Heerdegen, 2023/11/20
- Re: Instead of pcase, Po Lu, 2023/11/19
- Re: Instead of pcase, Michael Heerdegen, 2023/11/20
- Re: Instead of pcase, Dmitry Gutov, 2023/11/20
- Re: Instead of pcase, Po Lu, 2023/11/20
- Re: Instead of pcase, Dmitry Gutov, 2023/11/20
- Re: Instead of pcase, Po Lu, 2023/11/20
- Re: Instead of pcase, Dmitry Gutov, 2023/11/20
- Re: Instead of pcase, Po Lu, 2023/11/20