Should `position' be implemented in Emacs core and preloaded?

Should `position' be implemented in Emacs core and preloaded?

[Tino Calancha]

Hello Emacs,

sometimes i wonder why functions as useful as `position'
are an alias for `cl-position' instead of part of the core. I mean,
they could be implemented out of cl-lib and be preloaded.
Maybe for other more specialized functions is reasonable to load
`cl-lib', but IMO not to just use a fundamental function
as `position' is.

The functions i have in mind are: `position', `position-if',
`position-if-not' and `subsetp'.

*) `position': very fundamental operation on a sequence.  It
     deserves to be preloaded.
*) `position-if': i like this function very much, it's powerful.
*) `position-if-not': similar as previous one.
*) `subsetp': Another fundamental operation; it allow to check if
     several elements belong to one sequence in a compact way.
     For instance, compare:

(let ((options '(?a ?b ?v ?c)))
   (when (and (member ?a options)
              (member ?b options)
              (member ?c options))
     (message "All are included")))
=> "All are included"

;; with:

(let ((options '(?a ?b ?v ?c)))
   (when (subsetp '(?a ?b ?c) options)
     (message "All are included")))
=> "All are included"

I) We might implement them in, for instance, subr.el.
    This could break backward compatibility in code using
    the alias in cl.el, though; not in the current Emacs
    source code AFAICT.

II) Alternatively, they could be implemented in a lighter
     lib; i guess the natural candidate is seq.el.
     Note that this lib already has `seq-position'.

III) We might keep everything as it is.

IV) Other options that i couldn't imagine.

I would be glad to read your opinions about this idea.
Thank you very much.
Tino

Re: Should `position' be implemented in Emacs core and preloaded?

[Stefan Monnier]

> II) Alternatively, they could be implemented in a lighter
>     lib; i guess the natural candidate is seq.el.
>     Note that this lib already has `seq-position'.

I consider seq.el as "core" already.  Actually, I also consider
cl-lib as "core".  The fact that you have to rite (require <..>) is
fairly secondary.

I think sooner or later, these libraries will be preloaded (not sure
which of the two will get there first, tho).

Also, FWIW, I don't see many uses of these cl/seq-position functions
in Emacs, so I'm not sure how important they are, really.


        Stefan

Re: Should `position' be implemented in Emacs core and preloaded?

[Tino Calancha]

On Wed, 5 Oct 2016, Stefan Monnier wrote:

>> II) Alternatively, they could be implemented in a lighter
>>     lib; i guess the natural candidate is seq.el.
>>     Note that this lib already has `seq-position'.
>
> I consider seq.el as "core" already.  Actually, I also consider
> cl-lib as "core".  The fact that you have to rite (require <..>) is
> fairly secondary.
Yes, you are right.  Of course, they are core Emacs.
What i meant is that it would be nice if people could use that 
kind of useful functions without face resistances.  I saw before
in this list people who wanted to use a function from cl-lib or seq.el,
and they received objections because that would force that file to
require such lib.

> I think sooner or later, these libraries will be preloaded (not sure
> which of the two will get there first, tho).
That sounds interesting.
> Also, FWIW, I don't see many uses of these cl/seq-position functions
> in Emacs, so I'm not sure how important they are, really.
I suspect that one important reason to not appear widely is exactly
that in order to use them we need to require the lib to use it.  Probably
if `member' would be just an alias to `cl-member', we wouldn't see it
as many times as we can see it now in Emacs tree.  I bet that if we follow
the I) above, we will start to see many uses of those functions in the new
code.

Re: Should `position' be implemented in Emacs core and preloaded?

[Stefan Monnier]

> What i meant is that it would be nice if people could use that kind of
> useful functions without face resistances.  I saw before
> in this list people who wanted to use a function from cl-lib or seq.el,
> and they received objections because that would force that file to
> require such lib.

Normally such resistance only appears when it would require preloading
seq or cl-lib (i.e. when it's used by a file which is itself preloaded).

I think preloading seq.el would be OK under the following conditions:
- seq.el is changed so as not to require cl-lib (that's mostly
  a question of moving shared code between the two libs so that it's in
  seq.el instead of in cl-lib, so it shouldn't be too difficult).
- one of the preloaded files really benefits from seq.el.

>> Also, FWIW, I don't see many uses of these cl/seq-position functions
>> in Emacs, so I'm not sure how important they are, really.
> I suspect that one important reason to not appear widely is exactly
> that in order to use them we need to require the lib to use it.

You might be right.  I guess there's also the fact that on singly-linked
lists, using seq-position is rarely the best way (in terms of
efficiency) to get the job done.


        Stefan

Re: Should `position' be implemented in Emacs core and preloaded?

[Tino Calancha]

On Wed, 5 Oct 2016, Stefan Monnier wrote:

>> What i meant is that it would be nice if people could use that kind of
>> useful functions without face resistances.  I saw before
>> in this list people who wanted to use a function from cl-lib or seq.el,
>> and they received objections because that would force that file to
>> require such lib.
>
> Normally such resistance only appears when it would require preloading
> seq or cl-lib (i.e. when it's used by a file which is itself preloaded).
>
> I think preloading seq.el would be OK under the following conditions:
> - seq.el is changed so as not to require cl-lib (that's mostly
>  a question of moving shared code between the two libs so that it's in
>  seq.el instead of in cl-lib, so it shouldn't be too difficult).
> - one of the preloaded files really benefits from seq.el.
I support this idea; seq.el is light and efficient so let's use it more.