all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: Why aren't there functions such as filter, take-while, etc. "by  default"?
Date: Mon, 26 Apr 2010 10:29:56 +0200	[thread overview]
Message-ID: <87eii24nwb.fsf@lola.goethe.zz> (raw)
In-Reply-To: jwveii2opbr.fsf-monnier+emacs@gnu.org

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

>>> Why does it have to be so hard to write Emacs Lisp without requiring cl?
>>> Why aren't there functions such as filter (the equivalent of
>>> remove-if-not in cl-seq.el), take-while, reduce etc. "native" in
>>> Emacs?
>> They make for no-surprise efficient programs primarily when the language
>> has lexical closures.
>
> I do not understand this.  What do you mean to say, and why is dynamic
> scoping relevant (i.e. why wouldn't the same argument apply to mapcar,
> mapconcat, etc...).

It does apply to the latter functions equally well.  However, those tend
to be usable with primitive functions without dynamic consequences
somewhat more often.

The more complex filtering functions of Common Lisp are very much
employed as an alternate programming style for iteration.  If there is
no conceivable way to transform them into byte code (or whatever) with a
similar efficiency and predictability as the equivalent iteration code,
they seem like a bad idea.

When learning Elisp, I have been negatively surprised by the bad
performance of using map* functions as opposed to straight iteration.

I should really like to see a version of Elisp where one-shot lambda
functions with outer references
a) need not be written
  (let ((outer ...)) ... `(lambda (x) (... ',outer ...
b) byte compile into the same or equally efficient byte code as their
   open-coded iteration equivalents

It is ok if the debugger can use debugging info/signatures for
approximating dynamical access for the user to the anonymous stack slots
of lexical variables, but normal operation should not be affected.

Since Lisp, after all, is supposed to be a functional language, I'd like
to see Emacs Lisp not penalize functional programming styles.  Currently
it does, and so I don't think general-purpose iteration constructs
encouraging lambda predicates are a good idea for now.

It would appear that both the lexbind branch as well as an all-out guile
strategy could provide paths forward.  The latter would seem to have the
advantage that we can get rid of the whole byte compilation issue in the
Emacs codebase (which would likely get more rather than less complex
with lexbind).  _And_ give guile a large kick forward in improvement
incentives.  Likely more than the boost that the Emacs project gives
Bazaar, and with more immediate benefits.

-- 
David Kastrup





  reply	other threads:[~2010-04-26  8:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-24 20:13 Why aren't there functions such as filter, take-while, etc. "by default"? Deniz Dogan
2010-04-25 16:24 ` David Kastrup
2010-04-25 19:09   ` Štěpán Němec
2010-04-25 20:27   ` Deniz Dogan
2010-04-25 22:56     ` Drew Adams
2010-04-25 23:10       ` Deniz Dogan
2010-04-26  3:39   ` Stefan Monnier
2010-04-26  8:29     ` David Kastrup [this message]
2010-04-26  8:35       ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eii24nwb.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.