[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: Garreau\, Alexandre
Subject: Re: Replace trivial pcase occurrences in the Emacs sources
Date: Sat, 27 Oct 2018 18:56:11 +0200
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, modified by Debian

On 2018-10-27 at 17:19, Michael Heerdegen wrote:
> What's then left is the task to replace all pcase forms that can be
> trivially rewritten by using case or cond/assoc.  I must admit that
> I'm very skeptical about this now.  Not only that we would only
> replace exactly these pcase occurrences that are really trivial to
> read for anybody, which could be, at the end, counterproductive for
> those people who dislike pcase because the pcase forms left are the
> harder ones (Eli, I know you don't think like that).
> I also saw that people have very different likings, independent from
> pcase.  Say, we have one third of people who want to keep pcase in
> these cases, one third who want to replace it with cl-case, and one
> third who want cond or assoc instead.  We have a clear majority
> against pcase.  But we also have a clear majority against cl-case, and
> a majority against cond/assoc.

First of all, on a practical ground, I’m not sure anything has been that
democratic yet, or anybody has found a that-much democratic process to
be useful (at least it is complex to, well, process)…

But, as the question is raised, that recalls me a lot Arrow’s paradox:
normally this is the moment I notice you that each one of these thirds
may have a preference too about the two forms they dislike (or only like
less; for instance I might be a fan of case but prefer cond and assoc to
pcase (or the other way around)), so we might ask a list of preferences
rather than a single preference, and Arrow’s paradox says this issue
keep going as in the end the comparisons may be A > B > C > A.

Fyi, one solution of this paradox, is to allow multiple equalities (such
as giving preferences in the form A = B > C = D), and do a median rather
than a average/direct-superiority-count-compare, or, in a more
intuitive, developed and straightforward way: “in a ringle round, give a
notation mark to each preference, then for each preference, take their
median score, take the winner(s), and if several, the one who won by
this score by more voices” (very unlikely to get equalities).

More pretty interesting documentation on arrow paradox:

reply via email to

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