emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Lisp files that load cl-lib in problematical ways


From: Drew Adams
Subject: RE: [External] : Re: Lisp files that load cl-lib in problematical ways
Date: Sun, 29 Oct 2023 17:16:31 +0000

> If one were to compare apples to apples one could
> argue that CL's functions are _more_  accessible
> and quite well documented,

Yes, if you mean their documentation in the
Common Lisp reference doc (esp. CLTL2, but even
the Hyperspec).

But no, not so well documented, if you mean the
Emacs doc for them.  (Just one opinion.)

> both the thought put into the design of those
> interfaces and the use they've seen by Lisp
> programmers of various breeds far exceed those
> of seq.el and pcase.el.

+1.  Far exceed.

Personally, I'd prefer that the Common Lisp
sequence functions just be added to Elisp, in
place of those in seq.el - keeping anything
truly Elisp-specific and found to be sorely
missing from C.L.  (Of course, this might mean
supporting their keyword args.)

I can't speak so definitively about `pcase.el'.
Some C.L. things could be used directly in place
of some of what `pcase' etc. do.  But patterned
binding, which pcase also does, is very useful.

(Patterned binding could usefully be separate
from any conditional behavior, but that's just
a personal opinion, and far down the river
that's passed under the bridge.)

By "just add to Elisp" I mean essentially (1)
get rid of the `cl-' prefix and (2) add the
construct, preferably "full-blown" but limited
in some ways if necessary, to Elisp.  Some
constructs could be preloaded, some autoloaded.
___

Every few months or so we hear input about
vastly multiplying the number of Emacs users
by changing this or that behavior or name to
something that potential newcomers might be
more familiar with.

There might be something to say, in terms of
leveraging existing familiarity with C.L. (and
perhaps in terms of reuse of some existing
C.L. code out there), for integrating more
C.L. stuff directly into Elisp.  The C.L.
"community" might not be on the order of, say,
the JavaScript or Python "community"..., but
still.  (And I'm pretty sure that many C.L.
programmers already use Emacs.)

Again, just one opinion.

(You might note that I'm both (1) for _not_
requiring `cl-lib.el' gratuitously in my
libraries and (2) integrating some more of
`cl-*.el' into Elisp.  For me, that's not a
contradiction.  If it seems to be one for
someone else, so be it.)

reply via email to

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