Re: [PATCH] What's the quickest way to contribute?

[Stefan Monnier]

>> I think algorithmically, it's equivalent (both are O(N), basically).
> Yes, I've used my blurry version of *algorithmically faster*, which
> means iterating on one list instead of two in succession; the
> complexity is the same, of course.

As mentioned, I expect the second traversal (the `delq') to be
negligible, because it's a simple loop 100% implemented in C (in the
mapcar, most of the time is likely to be spent in the function-call made
for each element, and in the remove-if a similar amount of time is
probably spent in interpreting the byte-code that performs the
iteration).

>> Yes, cl-* functions are definitely allowed.  There is of course a lot of
>> carried prejudice from when cl-* functions didn't exist (and we just
>> had the `remove-if-not' instead, whose use was not accepted in Emacs's
>> own code), but there is also still a restriction in this respect: cl-*
>> functions still can't be used from preloaded files (because that would
>> require preloading cl-lib).
> By preloaded files, do you mean the ones on `preloaded-file-list'?

Yes.

> There are 112 files in this list on my system, so it's quite a large
> restriction.

Indeed.  It is very slightly relaxed by the fact that some of those cl-*
functions come with compiler-macros so some calls can be used because
they can be macro-expanded away during compilation (e.g. cl-list* and
cl-caddr, and I may have a patch somewhere that does it for cl-remove-if
and cl-remove-if-not).

> Is it no-more, no-less, i.e. only these 112 files?

That's right.

> Maybe the byte compiler could do some linting to enforce this
> restriction?  It already contains a lot of checks.

There is such a check already: if you use (eval-when-compile (require
'cl-lib)), the compiler should tell you if you use a function from
cl-lib.  And if you use (require 'cl-lib) instead, the compiler will
stay silent, but the "dump" phase (where we preload the files) should
complain that you're requiring a file that isn't explicitly loaded.


        Stefan