Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Nicolas Petton]

Hi guys,

Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
`remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
or use dash, but I'm wondering why these functions are not part of the
base language?

Nico

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
> or use dash, but I'm wondering why these functions are not part of the
> base language?

Not sure what you mean.  Most languages I know provide list operations
via libraries.  Why should Elisp be different?


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Nicolas Petton]

Stefan Monnier writes:

>> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
>> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
>> or use dash, but I'm wondering why these functions are not part of the
>> base language?
>
> Not sure what you mean.  Most languages I know provide list operations
> via libraries.  Why should Elisp be different?

What I mean is that Elisp do not have `remove-if` (or any equivalent
function, I don't necessarily mean the CL remove-if function), a
function that I think could be in the language.

To filter lists, one has to implement its own version of this function,
or require an external library. Same goes for `find-if`. 

I was wondering if Emacs Lisp was lacking this function for some reason
(or did I completely miss it? could be too). If not, why not add it to
the language? It looks to me like a badly missing feature, I think
filtering collections is something very common.

Cheers,
Nico

RE: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Doug Lewan]

While I won't make assertions about how Emacs Lisp as a language should be, I am comfortable saying that I write code like the following a lot:

    (delete nil (mapcar ...))

,Douglas
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224

LISP: The most intelligent way to misuse a computer.

> -----Original Message-----
> From: help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org
> [mailto:help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org] On
> Behalf Of Nicolas Petton
> Sent: Tuesday, 2014 June 17 14:37
> To: Stefan Monnier
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs
> Lisp?
> 
> 
> Stefan Monnier writes:
> 
> >> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
> >> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-
> lib
> >> or use dash, but I'm wondering why these functions are not part of
> the
> >> base language?
> >
> > Not sure what you mean.  Most languages I know provide list
> operations
> > via libraries.  Why should Elisp be different?
> 
> What I mean is that Elisp do not have `remove-if` (or any equivalent
> function, I don't necessarily mean the CL remove-if function), a
> function that I think could be in the language.
> 
> To filter lists, one has to implement its own version of this function,
> or require an external library. Same goes for `find-if`.
> 
> I was wondering if Emacs Lisp was lacking this function for some reason
> (or did I completely miss it? could be too). If not, why not add it to
> the language? It looks to me like a badly missing feature, I think
> filtering collections is something very common.
> 
> Cheers,
> Nico

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Nicolas Petton]

Doug Lewan writes:

> While I won't make assertions about how Emacs Lisp as a language should be, I am comfortable saying that I write code like the following a lot:
>
>     (delete nil (mapcar ...))

Do you mean that you are ok with using the above or that you'd like to
have remove-if built into the language?

>
> ,Douglas
> Douglas Lewan
> Shubert Ticketing
> (201) 489-8600 ext 224
>
> LISP: The most intelligent way to misuse a computer.
>
>> -----Original Message-----
>> From: help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org
>> [mailto:help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org] On
>> Behalf Of Nicolas Petton
>> Sent: Tuesday, 2014 June 17 14:37
>> To: Stefan Monnier
>> Cc: help-gnu-emacs@gnu.org
>> Subject: Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs
>> Lisp?
>> 
>> 
>> Stefan Monnier writes:
>> 
>> >> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
>> >> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-
>> lib
>> >> or use dash, but I'm wondering why these functions are not part of
>> the
>> >> base language?
>> >
>> > Not sure what you mean.  Most languages I know provide list
>> operations
>> > via libraries.  Why should Elisp be different?
>> 
>> What I mean is that Elisp do not have `remove-if` (or any equivalent
>> function, I don't necessarily mean the CL remove-if function), a
>> function that I think could be in the language.
>> 
>> To filter lists, one has to implement its own version of this function,
>> or require an external library. Same goes for `find-if`.
>> 
>> I was wondering if Emacs Lisp was lacking this function for some reason
>> (or did I completely miss it? could be too). If not, why not add it to
>> the language? It looks to me like a badly missing feature, I think
>> filtering collections is something very common.
>> 
>> Cheers,
>> Nico

RE: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Doug Lewan]

> -----Original Message-----
> From: Nicolas Petton 
> Subject: Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs
> Lisp?
> 
> Doug Lewan writes:
> 
> > While I won't make assertions about how Emacs Lisp as a language
> should be, I am comfortable saying that I write code like the following
> a lot:
> >
> >     (delete nil (mapcar ...))
> 
> Do you mean that you are ok with using the above or that you'd like to
> have remove-if built into the language?
> 

I only wanted to say that (*-if) would be very natural.

No language is perfect, if only because size versus completeness will never have a balance that makes everyone happy. (Think: assembler on one end and ADA on the other (or, gasp! Wolfram).) This is a compromise every programmer lives with. Emacs Lisp has a pretty good library, but is big enough that I still find new things just stumbling through the *Info*.

,Douglas
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224

LISP: The most intelligent way to misuse a computer.

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

>>> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
>>> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
>>> or use dash, but I'm wondering why these functions are not part of the
>>> base language?
>> Not sure what you mean.  Most languages I know provide list operations
>> via libraries.  Why should Elisp be different?
> What I mean is that Elisp do not have `remove-if`

Of course it does, tho it calls it `cl-remove-if'.


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Nicolas Petton]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
>>>> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
>>>> or use dash, but I'm wondering why these functions are not part of the
>>>> base language?
>>> Not sure what you mean.  Most languages I know provide list operations
>>> via libraries.  Why should Elisp be different?
>> What I mean is that Elisp do not have `remove-if`
>
> Of course it does, tho it calls it `cl-remove-if'.

Yes, but what I meant was that there is no filtering function in Elisp
itself (cl-remove-if is part of cl-lib).

But Barry's answer explains it. Now I'm wondering if it would make sense
to have such functions in Elisp itself?

Nico

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

>>>>> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
>>>>> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
>>>>> or use dash, but I'm wondering why these functions are not part of the
>>>>> base language?
>>>> Not sure what you mean.  Most languages I know provide list operations
>>>> via libraries.  Why should Elisp be different?
>>> What I mean is that Elisp do not have `remove-if`
>> Of course it does, tho it calls it `cl-remove-if'.
> Yes, but what I meant was that there is no filtering function in Elisp
> itself (cl-remove-if is part of cl-lib).

And as I said, it's generally considered normal that list manipulation
functions (such as remove-if) are not part of the core language but are
instead provided via libraries (such as `cl-lib').

> But Barry's answer explains it. Now I'm wondering if it would make sense
> to have such functions in Elisp itself?

So, fundamentally, it's just the (require cl-lib) that annoys you?


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Barry Margolin]

In article <mailman.3879.1403089222.1147.help-gnu-emacs@gnu.org>,
 Nicolas Petton <petton.nicolas@gmail.com> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>>> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
> >>>> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
> >>>> or use dash, but I'm wondering why these functions are not part of the
> >>>> base language?
> >>> Not sure what you mean.  Most languages I know provide list operations
> >>> via libraries.  Why should Elisp be different?
> >> What I mean is that Elisp do not have `remove-if`
> >
> > Of course it does, tho it calls it `cl-remove-if'.
> 
> Yes, but what I meant was that there is no filtering function in Elisp
> itself (cl-remove-if is part of cl-lib).
> 
> But Barry's answer explains it. Now I'm wondering if it would make sense
> to have such functions in Elisp itself?

Why? Just to avoid having to do (require 'cl)? Or are you suggesting 
that they should be rewritten in C and made primitive subrs?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Damien Cassou]

On Wed, Jun 18, 2014 at 4:43 PM, Barry Margolin <barmar@alum.mit.edu> wrote:

> Why? Just to avoid having to do (require 'cl)? Or are you suggesting
> that they should be rewritten in C and made primitive subrs?
>


I think Nicolas' problem is not the language in which the functions are
implemented. In my opinion, the problems are:

- that a (large) library must be loaded to have these 2 core functions
(select a subset of elements, select one element). And this library is not
required for similar functions like mapcar

- that the name of the cl-lib functions are all prefixed by 'cl-' which
makes them look weird for core functions

I don't think Nicolas cares about the exact same features as cl-remove-if
and cl-find-if. A very simple alternative (i.e., without the &rest cl-keys)
would do the job.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing
enthusiasm."
Winston Churchill

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Phillip Lord]

Damien Cassou <damien.cassou@gmail.com> writes:
>
 On Wed, Jun 18, 2014 at 4:43 PM, Barry Margolin <barmar@alum.mit.edu> wrote:
>
>> Why? Just to avoid having to do (require 'cl)? Or are you suggesting
>> that they should be rewritten in C and made primitive subrs?
>>
>
>
> I think Nicolas' problem is not the language in which the functions are
> implemented. In my opinion, the problems are:
>
> - that a (large) library must be loaded to have these 2 core functions
> (select a subset of elements, select one element). And this library is not
> required for similar functions like mapcar
>
> - that the name of the cl-lib functions are all prefixed by 'cl-' which
> makes them look weird for core functions
>
> I don't think Nicolas cares about the exact same features as cl-remove-if
> and cl-find-if. A very simple alternative (i.e., without the &rest cl-keys)
> would do the job.


I think that dash addresses most of these. The namespacing is minimal
(with a -) and it's not particularly large, although in these days of
fast machines, I am not sure that "large" is such a problem as it might
have been in the past. I am often surprised by how much emacs can do
nowadays which would have been slow before.

Phil

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Christoph Wedler]

Damien Cassou <damien.cassou@gmail.com> writes:

> On Wed, Jun 18, 2014 at 4:43 PM, Barry Margolin <barmar@alum.mit.edu> wrote:
>
>> Why? Just to avoid having to do (require 'cl)? Or are you suggesting
>> that they should be rewritten in C and made primitive subrs?
>
> I think Nicolas' problem is not the language in which the functions are
> implemented. In my opinion, the problems are:
>
> - that a (large) library must be loaded to have these 2 core functions
> (select a subset of elements, select one element). And this library is not
> required for similar functions like mapcar
>
> - that the name of the cl-lib functions are all prefixed by 'cl-' which
> makes them look weird for core functions
>
> I don't think Nicolas cares about the exact same features as cl-remove-if
> and cl-find-if. A very simple alternative (i.e., without the &rest cl-keys)
> would do the job.

Indeed, the "cl-" prefix is very weird.  I would consider almost all CL
functions core, with the exception of (cl-)loop.

Btw, in Emacs-24.3, syntax highlighting does not work for cl-defstruct,
but defstruct.


To be honest, I do not fully understand why Emacs has such an anti-CL
policy.

Sometimes, you hear the "namespace argument" ("polution"): Well, to put
that into perspective, you might want to check the EMACS/etc/NEWS*
files.  There, you see quite a few "new function" announcements without
extra namespace, quite a few are actually the CL functions... (repeated
"namespace polutions" are IMHO worse than one bigger one).

Regards,
Christoph

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Barry Margolin]

In article <wfker42etnyi.fsf@sap.com>,
 Christoph Wedler <christoph.wedler@sap.com> wrote:

> To be honest, I do not fully understand why Emacs has such an anti-CL
> policy.

Basically, RMS thinks CL is too bloated. From 
http://www.gnu.org/gnu/rms-lisp.html:

Obviously, machines are bigger now, and we don't do it that way any 
more. We put in 'caar' and 'cadr' and so on, and we might put in another 
looping construct one of these days. We're willing to extend it some 
now, but we don't want to extend it to the level of common Lisp. I 
implemented Common Lisp once on the Lisp machine, and I'm not all that 
happy with it. One thing I don't like terribly much is keyword arguments 
(8). They don't seem quite Lispy to me; I'll do it sometimes but I 
minimize the times when I do that.

Footnote (8) says:

I don't mind if a very complex and heavyweight function takes keyword 
arguments. What bothers me is making simple basic functions such as 
"member" use them.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

> I don't mind if a very complex and heavyweight function takes keyword
> arguments.  What bothers me is making simple basic functions such as
> "member" use them.

Agreed.  They also work OK for macros since those are not supposed to be
executed at run-time.  Keyword arguments are particularly problematic in
Elisp where the language implementations are all fairly simplistic with
very limited optimizations.


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Leo Liu]

On 2014-06-24 23:22 -0400, Stefan Monnier wrote:
> Agreed.  They also work OK for macros since those are not supposed to be
> executed at run-time.  Keyword arguments are particularly problematic in
> Elisp where the language implementations are all fairly simplistic with
> very limited optimizations.
>
>
>         Stefan

I think the issue with CL.el is it was castigated in the official manual
too early. It isn't bloated by any standard today. There are many things
in emacs that do less with more mess and bloat. For me I always pretend
cl.el is preloaded and happily use it. It surprise me many times how
thoughtful it is and I felt a bit of thrill when I reduced half of dozen
lines of code to one with clever combination of arguments. Sometimes I
take a moment to wonder how can those bastards foresee such a use case
;)

Leo

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

> I think the issue with CL.el is it was castigated in the official manual
> too early.  It isn't bloated by any standard today.  There are many things
> in emacs that do less with more mess and bloat.

Part of the issue was bloat, but another part was that cl.el was
developed as an independent add-on (i.e. under the assumption that the
rest of Emacs couldn't be changed, such as byte-compiler, macroexpander,
...), so it had to use pretty ugly hacks (whose effects could affect
(apparently) completely unrelated code) to implement some of its
features.  Over time, some of the needed infrastructure was added to
core Elisp, so the cl.el implementation gradually became cleaner.

The current cl-lib.el still has a couple of ugly hacks, but fairly few
and their effect should be reasonably confined to code that uses them.


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Christoph Wedler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Barry Margolin <barmar@alum.mit.edu> writes:

>> Basically, RMS thinks CL is too bloated. From 
>> http://www.gnu.org/gnu/rms-lisp.html:
>
>> Obviously, machines are bigger now, and we don't do it that way any 
>> more. We put in 'caar' and 'cadr' and so on, and we might put in another 
>> looping construct one of these days. We're willing to extend it some 
>> now, but we don't want to extend it to the level of common Lisp.

Actually, nowadays the "bloated argument" can be reversed: because many
ELisp libraries basically reimplement specialized versions of many CL
functions, the complete ELisp code (and even subsets of average-used
size) is more bloated that CL + libs that make use of CL.

>> I implemented Common Lisp once on the Lisp machine, and I'm not all that 
>> happy with it. One thing I don't like terribly much is keyword arguments 
>> (8). They don't seem quite Lispy to me;

Hm, there are good reasons why :KEYWORD is specially highlighted by
font-lock - it is also used in custom, face/display specs, ...  It might
be un-early-Lispy...  OK, loop is un-Lispy (and bloated).

>> (8) I don't mind if a very complex and heavyweight function takes keyword
>> arguments.  What bothers me is making simple basic functions such as
>> "member" use them.

To be honest, I like keyword arguments a lot - whenever the meaning of a
parameter is not clear from its position, it should be a keyword
parameter.  If you look at existing functions, the sequence of the
parameter can quite often only be explained by the history of that
function.

What is wrong with the keyword parameters :test, :test-not and :key of
cl-member (should be `member' ;-)) - which position do you want to give
them - or do you want to invent extra function names for them?

> Agreed.  They also work OK for macros since those are not supposed to be
> executed at run-time.  Keyword arguments are particularly problematic in
> Elisp where the language implementations are all fairly simplistic with
> very limited optimizations.

That might be a description of todays implementation.  I would assume
that you could compile away the keyword parameters relativly easily: you
basically attach a define-compiler-macro (another CL macro) which maps
the keyword parameters to positional parameters.

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

>> Agreed.  They also work OK for macros since those are not supposed to be
>> executed at run-time.  Keyword arguments are particularly problematic in
>> Elisp where the language implementations are all fairly simplistic with
>> very limited optimizations.
> That might be a description of todays implementation.  I would assume
> that you could compile away the keyword parameters relativly easily: you
> basically attach a define-compiler-macro (another CL macro) which maps
> the keyword parameters to positional parameters.

Of course, cl-lib does this kind of thing, but it's a lot of work, so it
only covers some cases, and if you ever want to pass `member' to another
function define-compiler-macro won't help you and you get a major
performance penalty.

I agree with you that naming arguments can be *very* helpful.  But given
the current state of Elisp implementation, using keyword arguments with
functions that might be performance sensitive is not a good idea.


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

> That might be a description of todays implementation.  I would assume
> that you could compile away the keyword parameters relativly easily: you
> basically attach a define-compiler-macro (another CL macro) which maps
> the keyword parameters to positional parameters.

There's another problem with CL in this area: it tries to reproduce
(as faithfully as possible) the CL semantics, but in some cases, that
semantics doesn't *quite* match the Elisp semantics, so they have to
work much harder even if in 99% of the cases the difference is not
actually relevant.  E.g. in Elisp a missing optional argument is 100%
equivalent to a nil argument, whereas CL's optional argument can
distinguish the two cases, so an "&optional (x 3)" will have to be
macroexpanded into a "&rest args" and then checking the length of args
to see if the arg was provided or not.

If we were to add support for "&optional (x 3)" to Elisp, we'd either
need to change the C code that implements optional arguments, as well as
the byte-code format, so as to make the distinction between a nil and
a missing argument efficient (and get CL's semantics), or we'd just use
a simple macro-expansion approach and declare that nil is the same as
a missing argument: much simpler to implement and more in line with
usual Elisp practice.

This has happened time and time again: when Elisp incorporated a feature
present in cl.el, it typically did it in a slightly different way.
And usually the reasons are a mix of:
- because implementation simplicity is of utmost importance (given the
  lack of resources).
- because Elisp is not Common-Lisp, so the conventions, traditions, and
  expectations aren't quite the same.
- because we found a better way (e.g. compare gv-define-expander to
  define-setf-method).

Regarding macros and APIs, an important difference between Common-Lisp
and Elisp is that the expansion of a macro can only use "stable API
functions".  E.g. we can't just say "to modify this property, use (setf
<foo> ...)" and then consider the macro-expansion's result to be "an
internal detail that we can change at will" because the macroexpanded
code will be cast in stone in a foo.elc file that the user may still
want to use with Emacs-35.

So whichever setter function this `setf' method chose to use will have
to be preserved for many years.  We may elect not to advertise this
setter function, but even if we don't advertise it, we'll have to keep
supporting it to some extent.


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Barry Margolin]

In article <wfkeionpthgo.fsf@sap.com>,
 Christoph Wedler <christoph.wedler@sap.com> wrote:

> >> (8) I don't mind if a very complex and heavyweight function takes keyword
> >> arguments.  What bothers me is making simple basic functions such as
> >> "member" use them.
...
> What is wrong with the keyword parameters :test, :test-not and :key of
> cl-member (should be `member' ;-)) - which position do you want to give
> them - or do you want to invent extra function names for them?

I believe what RMS was saying is that they shouldn't have all those 
options at all -- they're no longer "simple basic functions". Yes, we do 
invent extra function names for them. Elisp (like Maclisp before it) has 
member and memq, while CL has a single function MEMBER with a :TEST 
option (and to make things worse, the default test is not the same as 
the Maclisp MEMBER function, it's more like MEMQ).

Note that CL isn't totally consistent about this. There are a number of 
functions that come in destructive and non-destructive versions (e.g. 
NCONC and APPEND), rather than a single function with a :DESTRUCTIVE 
option. In the case of APPEND/NCONC, this is necessary because they take 
all the arguments as a single &REST list, so there's no place to put 
options.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Robert Thorpe]

If it's a bad idea for Elisp to follow Common Lisp then how about some
Elispy functions?  That is, why not include in Emacs simple functions
like "find" that don't use keywords, like the Elisp's "member".  Those
could be made fast.  They could be named slightly differently too to
avoid namespace collisions, e.g. "find-item", "find-iff", "remove-iff",
etc.  Anyone who wants the Common Lisp ones can use cl-lib.el.

BR,
Robert Thorpe

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Pascal J. Bourguignon]

Nicolas Petton <petton.nicolas@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>>> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
>>>>> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
>>>>> or use dash, but I'm wondering why these functions are not part of the
>>>>> base language?
>>>> Not sure what you mean.  Most languages I know provide list operations
>>>> via libraries.  Why should Elisp be different?
>>> What I mean is that Elisp do not have `remove-if`
>>
>> Of course it does, tho it calls it `cl-remove-if'.
>
> Yes, but what I meant was that there is no filtering function in Elisp
> itself (cl-remove-if is part of cl-lib).
>
> But Barry's answer explains it. Now I'm wondering if it would make sense
> to have such functions in Elisp itself?

Yes, it would makes sense.  And just name them find, find-if, remove-if!

(defun remove-if (&rest args) (apply (function cl-remove-if) args))
;; …

-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[WJ]

Stefan Monnier wrote:

> Most languages I know provide list operations
> via libraries.

I hope that you are kidding.  If you're not, I hope that you have
nothing to do with the "development" (or hobbling) of Emacs Lisp.

Most languages that I know provide list operations without
loading a library.  There would be no reason not to.  List
operations are fundamental.

One should not have to load a package that emulates CL in order
to have the usual and expected list operations, and one should not
have to load a third-party library like Dash.

Racket:

 > (filter odd? '(0 1 2 3))
 '(1 3)

Bigloo Scheme:

1:=> (filter odd? '(0 1 2 3))
(1 3)

Clojure:

user=> (filter odd? [0 1 2 3])
(1 3)

Arc:

arc> (keep odd '(0 1 2 3))
(1 3)

NewLisp:

 > (filter odd? '(0 1 2 3))
 (1 3)

Julia:

julia> filter( isodd, [0 1 2 3] )
2-element Int32 Array:
 1
 3

Ruby:

[0,1,2,3].select( &:odd? )
    ==>[1, 3]

OCaml:

# List.filter (fun x -> x > 0) [0;1;2;3] ;;
- : int list = [1; 2; 3]

elisp:

: (mapcar #'1+ '(0 1 2 3))
(1 2 3 4)

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

> Ruby:

> [0,1,2,3].select( &:odd? )
>     ==>[1, 3]

Once you have a list object, then obviously, you've loaded
that library.  Doesn't mean that lists are part of the core language.

> # List.filter (fun x -> x > 0) [0;1;2;3] ;;
> - : int list = [1; 2; 3]

The "List." part proves my point here.


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Barry Margolin]

In article <mailman.3836.1403025251.1147.help-gnu-emacs@gnu.org>,
 Nicolas Petton <petton.nicolas@gmail.com> wrote:

> Hi guys,
> 
> Emacs Lisp is a great Lisp dialect, but I miss `find`, `find-if`,
> `remove-if`, etc. iteration functions a lot. Sure, I can require cl-lib
> or use dash, but I'm wondering why these functions are not part of the
> base language?

Emacs Lisp was mostly patterned after MACLISP. It didn't have these 
functions, either. I think they were introduced in ZetaLisp or NIL, and 
Common Lisp inherited them from these dialects. MACLISP didn't have as 
many of these higher-level functions as Common Lisp does. Elisp mostly 
added on stuff related specifically to editing and buffer management, 
but not much to do with basic data types like lists.

For a long time Elisp didn't even have floating point numbers!

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier]

> If it's a bad idea for Elisp to follow Common Lisp then how about some
> Elispy functions?

Because we already have the cl-* ones?


        Stefan

Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Barry Margolin]

In article <mailman.4322.1403739913.1147.help-gnu-emacs@gnu.org>,
 Robert Thorpe <rt@robertthorpeconsulting.com> wrote:

> If it's a bad idea for Elisp to follow Common Lisp then how about some
> Elispy functions?  That is, why not include in Emacs simple functions
> like "find" that don't use keywords, like the Elisp's "member".  Those
> could be made fast.  They could be named slightly differently too to
> avoid namespace collisions, e.g. "find-item", "find-iff", "remove-iff",
> etc.  Anyone who wants the Common Lisp ones can use cl-lib.el.

member and memq already do mostly the same thing as find, except the 
latter works on arrays as well as lists, and it returns an index instead 
of the tail of the list.

Maclisp got along for years without find. If it was good enough then, it 
should be good enough now. :)

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***