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

[Po Lu]

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.  My synthesis is roughly as follows:

  1. cl-lib is a comparatively large file.

  2. cl-lib is frequently loaded to provide trivial functions
     which could effortlessly be replaced by built-in constructs.

  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.

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.

> What's the gripe with compartments?  We don't have all of Elisp in
> a single library?  I was talking about namespaces by the way,
> if you didn't catch the reference (admittedly obscure)

Because Elisp isn't naturally partitioned into "compartments."  The
basic unit into which our code is divided is the file, and all
considerations must be framed on that basis.

> 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?

> These comparisons, taken one by one, are the hard evidence of that
> allows us to determine what is "alien" or not, not theological
> consecrations of personal tastes of a given group, _any_ group.
> For example, I don't think your 'nconc' form is more readable
> than 'cl-list*'.  It's slightly less readable IMO.  We could alias
> `list*` to nconc though, even better.  But I can agree it's not
> worth requiring cl-lib.el just for cl-list* alone.
>
> Much like you prefer setcar to rplacd. Which I also do, btw.  But
> I prefer (setf (car ...))  even more.  But you'll frequently see
> me using setcar and setcdr (or even rplacwahtevercannevertypeit)
> if that's the style of the file I'm working on.  Because I too
> have my personal tastes, but contrary to others I can let go of
> them without too much fuss.

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.

> Stefan M's pcase in particular is great.  Its docstring is tough,
> I agree, and could use some examples (I always end up grepping
> for examples).  But that macro is a lifesaver.
>
> The way you talk about seq.el and pcase.el makes me think you
> want to ban _all the things_, not just cl-lib.  I'm confused about
> what you want Elisp code in core to look like.

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