emacs-devel
[Top][All Lists]
Advanced

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

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


From: Gerd Möllmann
Subject: Re: What's missing in ELisp that makes people want to use cl-lib?
Date: Fri, 10 Nov 2023 08:05:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

João Távora <joaotavora@gmail.com> writes:

> On Thu, Nov 9, 2023 at 10:05 AM Alan Mackenzie <acm@muc.de> wrote:
>
>> >    If it needed any confirmation, I too like cl-lib and I too help
>> >    maintain other people's code in the Emacs core tree as well as
>> >    maintaining a number of libraries I have authored.
>>
>> There's a difference between liking cl-lib and advocating its
>> indiscriminate use.  I don't think you've done the latter in this (and
>> related) threads.
>
> Yes, you're right.  Indeed I don't' advocate for its indiscriminate use,
> just as I don't advocate for indiscriminate use of anything, except
> perhaps drinking water and brushing teeth.
>
>> Nobody who likes cl-lib has yet addressed the point made by Richard and
>> (less eloquently) by me, namely that the incorporation and use of cl-lib
>> swells the size and complexity of Emacs Lisp to the point of making
>> maintenance difficult.  What is your view on this important point?
>
> That it doesn't make maintenance any more difficult than any other
> Elisp construct, be it very old and curiously named like 'rplacd' or
> much, much newer like `seq-do` or `pcase-lambda`.
>
> My specific view on cl-lib.el is that it brings us a small part of
> the results of  non-trivial design work put in when important figures
> in the Lisp world met  regularly for many years to deliver what has
> proved to become excellent,  battle-tested, widely understood and
> impeccably documented programming abstractions.
>
> What I'm reading so far in this long discussion is that the argument
> of its detractors isn't really that cl-lib isn't good, but that
> it is superfluous and that learning it is a burden on maintainers.
> Well, it's just as superfluous as all of Elisp apart from two handfuls
> of primitives, I guess.  Or any programming language for that matter, if
> you know enough machine code.  Or any other programming abstraction I
> happen not to be familiar with.
>
> Also I seem to hear that Elisp has some kind of ideal hard-to-define
> identity or fingerprint and that it shouldn't try to become anything
> else.  But this argument is very strange given Elisp is, like any
> decent language, easy to extend.  Not to mention I struggle to see
> the technical advantage in uniqueness for uniqueness sake.  A good
> part of Elisp is about a special purpose function: editing buffers,
> and an the equally important part is about doing things with bits in
> memory, there's no reason to advocate for singularity here.
>
> I also hear Elisp shouldn't become Common Lisp, but not only is the
> use of cl-lib.el nowhere a step in that direction, but also -- somewhat
> ironically -- if Elisp _were_ Common Lisp, then that hard-to-define
> identity would be much easier to define and language extension would be
> much easier to organize into compartments to facilitate policy-making.
>
> Again, the only thing that has brought Elisp any closer to Common
> Lisp significantly, was the introduction of lexical binding some 10
> years ago.  Elisp looks a lot different now than it did in the 90's.
> Closures everywhere, higher-order functions!  Shudder!
>
> There's even talk of a continuation-passing style library, to
> be called future.el or promise.el or something.  Oh dear, what
> will be of us that we will have to evolve like any other language
> in the world!
>
> So I propose we let programmers use their judgement.  Really
> respect people who write code for no money and give the copyright
> away to the FSF.  Maybe suggest guidelines such as not introduce
> cl-loop where a dolist would do the job just as economically and
> elegantly. Don't use higher-order functions just because it looks
> cool. But maybe do suggest to use cl-position with a :key and a
> :test instead of a complex while loop with an auxiliary variable.
> Or cl-set-difference instead of nested loops.  Suggest to express
> intent, use abstractions.   Suggest to be consistent, be scrutinous,
> be "discriminate", be mindful of the style of the current area
> you are working on.
>
> But don't suggest anything too hard, especially if it's not
> modifying code you have authored.  Don't use arguments of authority
> when you can point to specific things.  Be generally respectful of
> people putting in any good work even if you don't like the style,
> and try to learn a new thing or two every now and then.
>
> BTW here are some nice generic suggestions from the Lisp world,
> written by two fenomenal programmers.  I love reading this from
> time to time:
>
>    https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf

Thanks, that was well written, João. I agree.



reply via email to

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