From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Lexical byte-compilation warnings cleanup Date: Tue, 20 Aug 2013 19:57:49 -0700 (PDT) Message-ID: <9c9d5439-3ef5-44a3-b886-bc95bddec03a@default> References: <5cd4c948-8187-4901-8c17-1db4c7288fe7@default> <6daf4da3-1d3a-4f4c-9db8-7174fb6da584@default> <87wqnfg675.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1377053893 1302 80.91.229.3 (21 Aug 2013 02:58:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Aug 2013 02:58:13 +0000 (UTC) Cc: Daniel Hackney , Stefan Monnier , Emacs development discussions To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 21 04:58:14 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VBycf-0002jx-Uz for ged-emacs-devel@m.gmane.org; Wed, 21 Aug 2013 04:58:14 +0200 Original-Received: from localhost ([::1]:51224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBycf-0002r3-Ld for ged-emacs-devel@m.gmane.org; Tue, 20 Aug 2013 22:58:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBycV-0002lX-0a for emacs-devel@gnu.org; Tue, 20 Aug 2013 22:58:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBycM-0000k8-EF for emacs-devel@gnu.org; Tue, 20 Aug 2013 22:58:02 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:24572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBycM-0000iY-8E for emacs-devel@gnu.org; Tue, 20 Aug 2013 22:57:54 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7L2vpKi013970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 02:57:52 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7L2voSj027217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 02:57:51 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7L2vouH003543; Wed, 21 Aug 2013 02:57:50 GMT In-Reply-To: <87wqnfg675.fsf@uwakimon.sk.tsukuba.ac.jp> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162943 Archived-At: > >>>> Indeed, it does not refer to the dynamically bound variable. > >>> Why is that? Will this be fixed, or is this the intended design? > >> Intended design. > > And the intention is? The design is? The reason is? >=20 > Give it up, Drew. RMS has never been one to prefer "a foolish > consistency" No one has argued for foolish consistency. Or even for consistency in this context. > (ie, adherence to abstract principles) Or for adherence to any abstract principles.=20 > where consistency collides with his intuition or hacking convenience, > and that same reliance on intuition appeals to current maintainers > as well: Nor has anyone argued against using intuition. That can sometimes be helpful. But FWIW I don't think that RMS was particularly one to shy from presenting his design choices explicitly and giving reasons for them. Anyway, that was then and this is now - I don't see much point in comparing with RMS here, either wrt the design or the process. It's not clear that RMS would have moved so quickly and cleanly toward integrating lexical scoping - and I'm glad that has been done. (No, sorry for the passive voice - I'm glad that Stefan did that.) But I would like to understand more (more than zero, at least) about the design intentions in this regard, and the reasons. Since there are 35 years of big brother Common Lisp's experience mixing lexical and dynamic binding in the same language, not to mention years of high-level discussion by Lisp implementors of all stripes to come up with that design in the first place, I would think that doing something quite different would prompt at least some discussion of alternatives, pros & cons, etc. That was admittedly a long time ago, and no doubt knowledge and technique have progressed since then. All the more reason why I would like to know something about what is behind this new approach. Aren't you curious at all why this difference wrt function parameters? That possibility never even occurred to me. I'm sure there are some reasons for the choices made, but they don't seem to be forthcoming. > > > As language designers, we just take idea from here and there. >=20 > I think that is the last word on Elisp design principles. Abstractly > I don't like it, myself, but surely you don't deny that it has proven > to be a workable strategy. Again, one can take ideas from here and there - no problem with that. But one takes this idea instead of that one for a reason. And that's what I'm asking about. Is it a good thing or a bad thing for more people to have an idea what the design is about and what motivates it? > Nevertheless there is hope for those who prefer care-full design: > Guilemacs! For the record, Guilemacs is not my hope. (Not that I'm sure what you mean by that term.) So far, the addition of lexical scoping to Emacs has not been far from the way it is mixed in with dynamic binding in Common Lisp, AFAICT. Naively, I would hope for Emacs Lisp to become more similar in this regard, not more different. But I'm no expert on any of this. Which is why I asked the question. And that's all I've done: ask why. I ask it again: why? The answer so far is to enable efficient interpretation. Sounds like that might be a promising reason, but so far that slogan means nothing to me. Does it mean something particular to you? Don't you want to know more about what is intended, and why, wrt this design which is presumably so important to Emacs and Emacs-Lisp programmers?