Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 00:38, Richard Stallman <rms@gnu.org> wrote:
>   > What about length= length/= length< length<= length> length>=
>   > predicates?
>
> One of the basic design guides of Emacs Lisp is rejection of
> the idea of adding more functions in the name of symmetry.

Interesting.  Where can I read about the "basic design guides of Emacs
Lisp"?

I looked at "(elisp) Programming Tips" but did not find anything.  rgrep
on the emacs repository shows some counter-examples, i.e. stuff added in
the name of symmetry.

It is not clear, what exactly "the idea of adding more functions in the
name of symmetry" means.  Elisp has = /= < > <= >= predicates.  Does it
mean that <= /= > >= are against that idea because they can be trivially
expressed using = and < so programmers should write those "expansions"
by hand all over the place?

rgrep gives me the following hits:

216 "(not (="
 19 "(not (>"
 12 "(not (<"
  3 "(not (<="
  1 "(not (>="
  0 "(not (/="

Each usage of not makes the code harder to reason about.

I personally prefer the following heuristic:

- use < and <= rather than > and >= (read the predicate left to right
  from smaller to bigger values)

- prefer when/unless/while/until and swap if branches to using /= or
  negation

This way there is almost no need for /= > >=, except they are still
needed for convenience when used in a different context, e.g. when
passed as an arg to a function.

> If there is a use for longer-than-p, or length> we could call it,
> it may be worth adding that function, but let's skip the other 5
> if they are not actually needed.

rgrep on the emacs repository gives me the following counts:

732 "(> (length"
703 "(= (length"
151 "(< (length"
 71 "(>= (length"
 66 "(<= (length"
 46 "(/= (length"

Using length in a predicate smells fischy.  It is most likely a source
of unnecessarily burned cpu cycles.  It might be futile to train
programmers to keep that in mind but it is relatively easy to find and
fix.

There are (+ 732 703 151 71 66 46) => 1769 potential cases in emacs.
That's quite a lot of potential low hanging fruit for improvement.

Defining all those predicates will allow to syntactically fix those
places without touching anything else.  Once those predicates are in
place, we can be _sure_ that emacs is not uselessly counting length of
lists in predicates.  And those predicates could be further improved and
optimized in the future without affecting the call sites.

Now the questions is, how should such predicates look like.  Ideally,
they would look like = /= < > <= >= (accepting rest args) and numbers or
lists where for lists lengths would be computed but short-circuited.
But such generality might be overkill so I do not have an oppinion on
that.

Another issue already raised was: in C or elisp?  If compiler-macros
were an option, maybe that would give the most flexible and efficient
implementation which would be easy to maintain.  But I do not know much
about such deep elisp details yet.