emacs-devel
[Top][All Lists]
Advanced

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

Re: Shrinking the C core


From: Emanuel Berg
Subject: Re: Shrinking the C core
Date: Thu, 07 Sep 2023 01:03:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Alan Mackenzie wrote:

>> I don't know why you reject them as clumsy, but why does it
>> matter to us if a tool includes features we don't use?
>
> It matters a very great deal. In practice you cannot avoid
> "using" these features if you have to understand or debug
> somebody else's code.

But it is up to him/her how [s]he writes his/her code.

>> I don't know if I understand it correctly, but CL was made
>> so other Lisps can be abstracted on top of it; so we use
>> those features to abstract stuff on top of those lengthy
>> verbose functions? In other words we can hide those keyword
>> params behind elispy abstractions if we don't like them?
>
> That's complexity and bloat. Far better not to have them in
> the first place.

Not everyone is a minimalist and certainly Emacs and Elisp
allow for maximalists as well.

>>> best avoided. All those keyword arguments! I intentionally
>>> excluded tham from Emacs and I am not going to let
>>> them in.
>>
>> I don't want to be impolite, but they are already in; via
>> cl-lib.el.
>
> Yes. There was a time not so long ago when cl.el was banned
> from use in our Lisp code, except for at compile time.
> Our Emacs Lisp was small, simple to understand, and easy to
> learn. Now things in cl-lib.el get used as if they are just
> a normal part of Emacs Lisp.

They are a normal part of Emacs Lisp by definition. Check out
cl-lib.el and see if you can find any CL there. This file is
part of GNU Emacs!

-- 
underground experts united
https://dataswamp.org/~incal




reply via email to

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