seq.el and the complexity of Emacs Lisp.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I looked at seq.el to try to get an idea what those functions do.  It
was difficult to get this from the doc strings, because it wasn't
explicitly stated which ones are for users and which ones are
internal.  Eventually I got somewhat of an idea. 

As for understanding the code itself, I basically couldn't the first
thing I saw used a macro `pcase-defmacro', and I have no idea what
that does.  (I generally find `pcase' cryptic and unclear, even if I
have read its documentation just before.)

Ultimately I did figure out what some of the user-facing features were
and understand what they did.  They seem clean enough -- both simpler
and more natural than the cl- sequence functions.

I expect that they are slower at run-time, because each seq- function
needs to do the generic dispatch for each call.  Is that correct?

Maybe we could speed this up by defining a function that's a no-op but
says that its argument is a list.  Using that function in the sequence
argument to a seq- function could tell all compilers to do the generic
dispatch at compile time.  It could be called `force-list' or `!list'.
There could also be `force-vector' too if it's worth the effort.

However, as regards the overall size or complexity of Emacs Lisp, it's
not a matter of comparing the seq- functions with the cl-lib functions
and the traditoinal Emacs Lisp functions and asking which is best.
That's the question you would face when deciding how to write a piece
of code.  However, as regards the language itself, what we have is
both the seq- fuctions and the traditoinal Emacs Lisp functions, with
some developers pushing the cl-lib functions into the combination.

If that continues, the complexity of Emacs Lisp will be the sum of the
three different ways or doing these things.  That is a big step for
the worse from where we started out.  The cost of these triplicated
language features affects both execution (memory usage) and human
thought (needing to know them all).

Could we replace all the cl-lib sequence function calls with seq-
calls, in core and GNU ELPA code?  Seq is simpler and cleaner, so that
would be an improvement.  We could keep cl-lib permanently for
compatibility for external code, but it would not need to be loaded
(into Emacs or your brain) very often.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)