[Top][All Lists]

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

Re: [GNU ELPA] New package: tam

From: Lynn Winebarger
Subject: Re: [GNU ELPA] New package: tam
Date: Wed, 20 Sep 2023 12:14:57 -0400

On Wed, Sep 20, 2023 at 4:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
> Re your last change in [0], why use records directly instead of having
> the code being generated via cl-defstruct?  The commit messages doesn't
> really explain your reasoning to me.

The library is supposed to provide alloc/free functions that run in
O(1) time to the extent that is possible for emacs-lisp code, for use
in process sentinels and similar situations.  I took a look at the
byte-code generated for those two functions when using the
cl-defstruct definitions, and the accessors and setters were not
inlined.  Aside from the unknown complexity of invoking those
functions, every call has a risk of overflowing the current stack and
requiring an additional stack segment be allocated.

I rewrote the code so the only appearances of the call operator in the
byte-code of those functions is for error signaling.  I also provide
an inlining version of each operation so library clients can avoid
call instructions in their code.

> >> I am the kind of person who thinks twice about installing a package when
> >> it has dependencies.  But if you prefer to use a package available on
> >> ELPA, then that is of course OK as well.

BTW, there's something ironic about this, since you actually appear to
review most packages on GNU/NonGNU ELPA - how many users would be more
familiar with the packages that might be installed from those
At any rate, it does not depend on any packages, or even cl-lib, now -
though I have to revise the header to say so.

> The question was supposed to be more general, sorry for the confusion.
> I wanted to know if there was a reason you were using setf even when
> setq would be enough, but it really doesn't matter either way since setf
> on a symbol expands directly to setq.

If I had setf on a symbol, it was a typo.  They are all gone now,
since they did not get optimized out.

> No, it uses nreverse:
> --8<---------------cut here---------------start------------->8---
> (macroexpand-all '(cl-loop for i to 10 collect i))
> (let* ((i 0) (--cl-var-- nil))
>   (while (<= i 10)
>     (setq --cl-var-- (cons i --cl-var--))
>     (setq i (+ i 1)))
>   (nreverse --cl-var--))
> --8<---------------cut here---------------end--------------->8---
Blech, I replaced it with a simple function.

> These kinds of arguments lead to leftpad like situations, where people
> defer any slightly complicated functionality to a library.  The last
> thing I want to see when installing a package is that it drags along
> dozens or even hundreds of recursive dependants, causing me to loose an
> overview of what I have installed and what is being installed.  Every
> dependency a package brings with it (especially packages like dash &
> co.) is an argument against using it, imo.

I don't think the leftpad situation (which I had to look up) can
happen on GNU ELPA.  Even if, despite the FSF's precautions, something
had to be removed, I'm sure there would be plenty of warning.


reply via email to

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