Tino Calancha <tino.calancha@gmail.com> writes:

> Dear Nico,

Hi Tino,

> I realize a delightful minimalist design choice in this lib:
> to keep just the minimum set of funtions providing same funcionality.
> For instance, seq.el has neither `seq-notevery' nor `seq-notany'
> which can be easily obtained as negation of `seq-every-p' and
> `seq-some'.

Glad you like it!

> Another example, instead of defining two functions per each operation
> ,as CL does (*) for several functions,
>
> I) func (seq, elt), one receiving args (SEQ ELT).
> II) func-if (pred, seq), other receiving args (PRED SEQ).
>
> seq.el seems to prefer introducing just the more general funcs in II) 
> (**).

Indeed, with some exceptions (that you already caught).

> There are two functions that escape from this logic.
> A) seq-position
>    I suggest to define this function so that it receives args as II),
>    like other functions in the file.
>    With the current definition, it is not possible to recover
>    the useful behaviour in II) (***).

I think this is a valid exception to the (pred, seq) signature of seq.el
methods.  The reason is that it would be counter-intuitive to retrieve
the position of an element in a sequence, which is really what
`seq-position' is about.

However, I could introduce another function that would take a predicate,
and `seq-position' could reuse it.  But I don't want to get rid of
`seq-position' as it exists today, I think it's too useful.

> B) seq-contains
>    Once you add this in the lib, the pair (seq-contains, seq-find)
>    is analog to CL (find, find-if).  This breaks the minimalist design
>    choice mentioned above.

Not exactly.  `seq-contains' might actually be a bit misleading.  It is
in essence a predicate, but it is not named `seq-contains-p' because it
returns the element if found.  Does that make more sense?

>    I believe `seq-contains' was introduced for convenience:
>    it is used elsewhere in seq.el and map.el.

It is indeed very convenient (as a predicate-ish function), and I think
that seq.el wouldn't be complete without it.

That said, renaming it `seq-contains-p' might clear things up, but OTOH
the function would lose part of its usefulness.

>    For consistency with the rest of the file, i would expect
>    not having defined `seq-contains', though.
>
> D) If the only dependence on 'cl-lib in seq.el is `cl-subseq',

There are all the generic functions as well which are defined in cl-lib.

>     Would be possible to include a func `seq-replace'
>     (stolen from `cl-replace')

I want to avoid side-effects on sequences as much as possible, so I
would vote against it.

>     That would remove the 'cl-lib dependence, one of the
>     arguments to not load 'seq at Emacs start up, AFAIK.
>     Does it have any sense?

Unfortunately, cl-lib will always be required for the generic functions.
That said, what I would really like is to see `cl-defgeneric' and
`cl-defmethod' be renamed and moved to Elisp core, they are so useful
and powerful.

Cheers,
Nico