From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Wedler Newsgroups: gmane.emacs.help Subject: Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp? Date: Wed, 25 Jun 2014 12:24:23 +0200 Organization: SAP AG 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 1403692270 4848 80.91.229.3 (25 Jun 2014 10:31:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 10:31:10 +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 12:31:06 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 1WzkTo-0007ke-BD for geh-help-gnu-emacs@m.gmane.org; Wed, 25 Jun 2014 12:31:04 +0200 Original-Received: from localhost ([::1]:36651 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzkTo-0006pd-0Q for geh-help-gnu-emacs@m.gmane.org; Wed, 25 Jun 2014 06:31:04 -0400 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!news1.dtag.de!news.sap-ag.de!news1!news.sap-ag.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 48 Original-NNTP-Posting-Host: nKU7bvDXFB5LzogK6rDeaQ.news.sap-ag.de Original-X-Trace: news.sap-ag.de 1403691863 12734 nKU7bvDXFB5LzogK6rDeaQ.news.sap-ag.de (25 Jun 2014 10:24:23 GMT) Original-X-Complaints-To: newsmaster@sap.com Original-NNTP-Posting-Date: Wed, 25 Jun 2014 10:24:23 +0000 (UTC) Cancel-Lock: sha1:XM6sSWszAF2kBcowbYFC9IecwD0= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) Original-Xref: usenet.stanford.edu gnu.emacs.help:206117 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:98388 Archived-At: Stefan Monnier writes: > Barry Margolin 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.