From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Return Date: Tue, 07 Dec 2010 16:54:29 +0100 Organization: Organization?!? Message-ID: <87bp4x37ey.fsf@lola.goethe.zz> References: <87mxojwu15.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4jnweng.fsf@uwakimon.sk.tsukuba.ac.jp> <87d3pdwt1x.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291737461 3856 80.91.229.12 (7 Dec 2010 15:57:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Dec 2010 15:57:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 07 16:57:37 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PPzur-00088q-UC for ged-emacs-devel@m.gmane.org; Tue, 07 Dec 2010 16:57:37 +0100 Original-Received: from localhost ([127.0.0.1]:54125 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPzur-0000cM-EL for ged-emacs-devel@m.gmane.org; Tue, 07 Dec 2010 10:57:21 -0500 Original-Received: from [140.186.70.92] (port=40894 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPzsP-0007fk-Dm for emacs-devel@gnu.org; Tue, 07 Dec 2010 10:54:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPzsO-00016Q-0S for emacs-devel@gnu.org; Tue, 07 Dec 2010 10:54:49 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:59477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPzsN-00015i-Ke for emacs-devel@gnu.org; Tue, 07 Dec 2010 10:54:47 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PPzsK-0006cF-Tb for emacs-devel@gnu.org; Tue, 07 Dec 2010 16:54:44 +0100 Original-Received: from p508ed86f.dip.t-dialin.net ([80.142.216.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Dec 2010 16:54:44 +0100 Original-Received: from dak by p508ed86f.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Dec 2010 16:54:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 78 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508ed86f.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:yibJCUYxpBZH4DmTu/ZT56b8c10= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133498 Archived-At: "Stephen J. Turnbull" writes: > MON KEY writes: > > > > [GvR] just doesn't think such [lambda or anon blocks] belong in > > > Python, and I have to admit I don't miss them. > > > > > > > I'e no clue whether this is good or bad for Python(istas) my > > concern is simply that this viewpoint not encroach upon the Emacs Lisp > > VM without qualification. :) > > No, it won't. However, I must say (as a maintainer) that use of > lambdas often imposes extra work on debuggers. I almost always give > lambdas a nickname when I'm reading code that uses them, unless > they're simply implementing partial evaluation. A nickname doesn't really apply well with closures. For debugging purposes, a "named lambda" might be helpful. Conceivably one could supply something like that using a DOC string. > Nobody says they are. But unless they hang out here, which they only > seem to do when they've got a bug report, they're not going to have > much influence on the future of the language. Given that RMS is > generally not in favor of incorporating Common Lisp features, I don't think anybody minds the features. The problem is the cost in syntactic complexity and language intransparency. cl is a large and invasive hack that is not particularly nice during debugging, decompiling and code design and optization. lexbind is a first step in a direction where some Common Lisp features become less costly. > > Yes but there is an accord to maintain some mutual consensus. AIUI > > your presence on this list is indicative of such an effort no? To > > paraphrase JWZ, "Now you have two problems." > > One of my problems is an addiction to email. The other is an > affection for David Kastrup. That is what my presence here indicates. Doing all the right things for ostensibly awfully bad reasons sounds like a form of compassionate nihilism designed to get out of the line of appreciation. After all, it could get you into serious trouble at /home/xemacs if somebody were as foolish as to, say, nominate you for the Free Software Award for minimizing, for whatever reason, the consequences of the great schism without losing face or focus. And it would look decidedly fishy if I were to do such a thing after this announcement. > More to the point, I long ago gave up on effecting a mutual consensus. > We either do it Emacs's way, or we don't. That's just the way it has > to be. I advocate things here that I think would be good for Emacs on > Emacs's own terms. I don't always get that right, but I'm definitely > not here to advocate the XEmacs way of thinking. You are advocating the Turnbull way of thinking, here and "there". At least here, mixed success is nothing to be worried about. > Frankly, I don't see any such general acknowledgement in the general > Emacs community. There is a significant subset of developers who > would like that, yes. But the non-developer users could care less, > and many developers either prefer a different style of language or > fear that incorporation of more features would lead to a deterioration > of performance for typical use-cases or instability in use, which > really isn't acceptable. I see much more the danger in bit rot. I've been considering helping with a dedicated lilypond-mode building on lyqi.el (there is a git repo for that). The code is an exercise in cl use and makes my eyes glaze over. I can't sensibly contribute, because it is utterly beyond me. Many times in Emacs programming, I give up on the documentation and just dig through the sources to see what something does deep down. cl does not lend itself to that approach. Its code is highly complex and utterly underdocumented. You have to trust it to do the right thing. I hate doing that. -- David Kastrup