Re: [GNU ELPA] New package: tam

[Philip Kaludercic]

Lynn Winebarger <owinebar@gmail.com> writes:

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

>From what I understand this situation was resolved in the other
subthread, right?

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

I don't know if this is ironic or not, I just don't like having too many
packages installed in general?  As I said, this is my personal taste and
I am not forcing this onto anyone.

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

OK.

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

Another idea could be using mapcan, but usually requires calling a
lambda expression -- at which point we have firmly reached the territory
of micro-optimisation, and it makes no sense to progress any further
without some substantial, empirical measurements and good technical
explanations behind the observations.

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

The point isn't so much that something gets removed (as you say, ELPA
plays the middle-man here by mirroring the repository contents), but
rather that a downstream bug or even a malicious change in a deep
dependency can cause much more harm, even if the inherent utility,
ie. need for the package in the first place was not that significant in
the first place.

> Lynn