From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.devel Subject: Re: cc-langs.el Date: Sat, 30 Aug 2003 21:42:08 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5bu17zc4q7.fsf@lister.roxen.com> References: <5bekzd29w7.fsf@lister.roxen.com> <5b7k547aov.fsf@lister.roxen.com> <5b1xv83wlr.fsf@lister.roxen.com> <5bfzjmgi2q.fsf@lister.roxen.com> <3F4FA043.7080602@yahoo.com> <87bru8caup.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: bug-cc-mode@gnu.org NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1062273830 9381 80.91.224.253 (30 Aug 2003 20:03:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 30 Aug 2003 20:03:50 +0000 (UTC) Cc: bug-cc-mode@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Aug 30 22:03:48 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19tBwq-0007mx-00 for ; Sat, 30 Aug 2003 22:03:48 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19tC4m-00032f-00 for ; Sat, 30 Aug 2003 22:12:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19tBvW-0007EG-Mt for emacs-devel@quimby.gnus.org; Sat, 30 Aug 2003 16:02:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 19tBvR-0007Ch-Md for emacs-devel@gnu.org; Sat, 30 Aug 2003 16:02:21 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 19tBvP-0007Aq-Aw for emacs-devel@gnu.org; Sat, 30 Aug 2003 16:02:20 -0400 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.22) id 19tBup-0006u1-BU; Sat, 30 Aug 2003 16:01:43 -0400 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 439AC99EB; Sat, 30 Aug 2003 21:42:09 +0200 (MEST) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 238CD99E1; Sat, 30 Aug 2003 21:42:07 +0200 (MEST) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 19tBbs-0006Tj-00; Sat, 30 Aug 2003 21:42:08 +0200 Original-To: emacs-devel@gnu.org In-Reply-To: <87bru8caup.fsf@tc-1-100.kawasaki.gol.ne.jp> (Miles Bader's message of "30 Aug 2003 08:17:34 +0900") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/20.7 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:16209 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:16209 Miles Bader wrote: > _Emacs lisp is not common lisp_. > > That means that however worthy these functions are (and I know they are > -- remember, I'm a common-lisp _fan_*), you can't just plop them into > elisp wholesale, you've got at least look at them, and how they fit into > elisp, and make decisions; interfaces and functions that are right for > common-lisp are not necessarily right for elisp. For a lot of > functions, that takes a fair amount of time. That was the intention with my list in this discussion; we collectively take a look on them and then, hopefully, agree on a set to include. I don't see how that could take an awful lot of time, but even if it does it's time well spent imho. Just saying "it's too much, it won't happen, e.o.d." is not good enough; I won't accept that as a reason for having to write cumbersome extra code to avoid these functions. > I realize that for sanity's sake, it would be best to use the same (or > at least very similar) interfaces for elisp functions as their > common-lisp counterparts, /.../ That's a very compelling reason for not meddling with their interfaces. An important point in "blessing" the CL functions instead of inventing something else is that they already been around for quite a while and are used in many places, albeit "only" at compile time in the standard packages. So, to further concretize the discussion let's bring up the specific issues that need to be considered. I can think of the following: o There are functions among the suggested ones that shouldn't be "blessed" for some reason. Well, I've already weeded out the ones that try to fix things like lexical binding and other stuff I suspect aren't reliable enough. Among those who remain that might be dubious are: - define-compiler-macro, if it doesn't work well enough with the compiler (otherwise it appears to be really useful), and - defstruct, which does a lot of stuff that I don't know how well it works (I've got no personal experience with it), and - more? o There might be more functions in the CL package that deserve to be considered. If so, those can be discussed later. o The CL map functions all accept more than one list to iterate over, whereas the built-ins only take one. When the function mapc got added as a built-in it lost that feature (which is a potential compatibility issue). I suggest that the multiple lists feature is kept, partly because it's useful occasionally, partly because it's compatible, and partly because it's no work (provided the functions remain written in lisp). It would lead to a slight inconsistency with the built-in mapcar and mapc, but that's only a minor ugliness that can be fixed later on without compatibility trouble. o The CL sequence and set functions all take keyword arguments like ":test" and ":key". That design is not new in elisp so it shouldn't be a problem per se, and the keywords are consistent and (imho) appropriate. Keeping those keywords introduces an inconsistency with the built-ins sort, remove, delete, member, assoc, and rassoc. The case is the same here as with mapcar and mapc: It's only a bit ugly and can be fixed at any time. Until then the CL counterparts ending with "*" can be used. o All the CL functions default to eql as test predicate, whereas the built-ins delete, remove, member, assoc, and rassoc use equal. This is also an inconsistency issue, but it's more serious since it can't be fixed without potential incompatibilities.