[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A few thoughts on seq.el
From: |
Nicolas Petton |
Subject: |
Re: A few thoughts on seq.el |
Date: |
Sun, 31 Jul 2016 19:36:13 +0200 |
User-agent: |
Notmuch/0.21 (https://notmuchmail.org) Emacs/25.1.50.1 (x86_64-unknown-linux-gnu) |
Tino Calancha <address@hidden> 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
signature.asc
Description: PGP signature