From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp? Date: Wed, 25 Jun 2014 10:09:53 -0400 Organization: A noiseless patient Spider Message-ID: References: <87d2e78nn7.fsf@gmail.com> <87bntr8jtc.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403705436 10682 80.91.229.3 (25 Jun 2014 14:10:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 14:10:36 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jun 25 16:10:30 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WznuA-0001RX-79 for geh-help-gnu-emacs@m.gmane.org; Wed, 25 Jun 2014 16:10:30 +0200 Original-Received: from localhost ([::1]:38051 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wznu9-0006QH-Oy for geh-help-gnu-emacs@m.gmane.org; Wed, 25 Jun 2014 10:10:29 -0400 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 48 Injection-Info: mx05.eternal-september.org; posting-host="80f6b1c01f068ad28ca734314fbfaa28"; logging-data="30634"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX180wdbRyjEBwqbgQc2PCVsu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:fft0mRyciSBQJX5CWYt33FtyBhs= sha1:CwiQ0MYpc8h128t+QPgp3K8NZV0= Original-Xref: usenet.stanford.edu gnu.emacs.help:206122 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:98393 Archived-At: > 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 ...)" 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