Re: What's missing in ELisp that makes people want to use cl-lib?

[João Távora]

On Fri, Nov 10, 2023 at 12:32 AM Po Lu <luangruo@yahoo.com> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > Are _you_ the suit?  I missed the point of most of your very
> > elegant text, but isn't policy-making exactly what you (and I) are
> > trying to do, i.e. discourage some things and encourage others?
>
> I'm not advocating partitioning Elisp into compartments, and to give
> countenance to some of them on the grounds of the stature of their
> designers.  That's your proposal.

What the heck?  What I said, is that if Elisp _had_ better
ways of making compartments, such as namespaces, managing which
compartments are preferred in certain parts of code would be easier.
I stated multiple times that I tend to trust developers to pick
the tools they find most appropriate for the job.  I simply stated
that it's funny and ironic that the language whose influence you're
trying to exorcize is precisely the one with one of the best
tools to do that exorcizing.

Maybe you didn't understand this because you're not familiar with
CL packages, so I can explain.  In CL you can actually write a program
in a package that doesn't ':USE' the :COMMON-LISP package at all, or
that only imports a handful of symbols from it (maybe the sacred
Elisp subset).  Or you can make your own packages with just the
symbols you want and maybe use that.  Meaning you'd be effectively
insulated from CL or at least the parts you don't like and could
write your perfect purist Lisp program.   Come on, isn't that funny?

>   3. cl-lib also defines a number of functions imported from a different
>      programming language, the beliefs underlying whose design don't
>      align with those of Emacs.

There are no "beliefs" in Common Lisp's, neither should there be
in Elisp.  I don't think it helps your case to repeatedly evoke
religion.

> Therefore, we should discourage cl-lib from being introduced in the
> first place, because its proliferation will render programmers more
> eager to use it without considering its implications.

Every other choice also has "implications".  Most people favourable
to cl-lib in this discussion know why they chose to use its functions.
I wouldn't be so condescending.

> > Also, is really cl-set-difference to take the difference
> > of two sets worse than writing a "hallowed" multi-line
> > construct??  Maybe I'm not seeing what the construct is, so
> > what is your preferred Elisp hallowed way to take the
> > difference of two sets, say make a list  that contains
> > all items that appear in LIST1 but not LIST2?  Or to find
> > the index of a certain element of a sequence...
>
> dolist with a catch/throw, or dolist, member and push?

Hmmm, a bit vague, no?  Humor me: if it's really so easy and so
readable please write out your preferred equivalent of, say

   (cl-set-difference l1 l2) ; hopefully obvious, like l1 - l2 in python

and

   ;; iterate through someseq and find index of first element
   ;; whose car matches probe according to 'probe-equals'.
   (cl-position probe someseq :key #'car :test #'probe-equals)

Shouldn't take long.  I can try myself, of course, but I think it's
fair to give the proponent of the alternate approach a shot before
comparing the two approaches.

> My point was that comparing rplaca to cl-lib is much the same as
> comparing apples to oranges, since rplaca is an _alias_ to setcar.

Some get confused by cl-labels, some by archaic things like rplaca,
some by new stuff like static-if.  Doesn't matter what is alias to
what, when you see both these things  in code you don't know what
they do until you look them up.  And many times you'll think "there's
a much better way".

> Well, touch-screen.el is a good example of that.

OK.  So, basically, your code :-) '(if x (progn ...))' instead
of 'cond', and lots of handrolled catch/throw with while t. OK fine.

I have a feeling I think you'd love cl-loop, maybe even too much :-)

Also quite some long functions there.  300 lines? Maybe typing
"touch-screen" each time to define and call functions
discourages you from modularizing more?  Or maybe it doesn't
bother you at all, so fine.

Don't get me wrong, I am very thankful for your contributions,
I really am.  Write Elisp code in the manner you find most
comfortable.  But there are programmers working on problem domains
in the core other than touch-screen.el, maybe with different
non-C backgrounds.  Many of them are historical contributors to
Emacs.

João