Re: [GNU ELPA] New package: tam

[Lynn Winebarger]

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

Lynn