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: e and pi Date: Fri, 17 Sep 2010 09:14:57 -0700 Message-ID: References: <8739t9xpt2.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1284740239 27650 80.91.229.12 (17 Sep 2010 16:17:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 17 Sep 2010 16:17:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Chong Yidong'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 17 18:17:14 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 1Owdca-0000O4-HZ for ged-emacs-devel@m.gmane.org; Fri, 17 Sep 2010 18:17:08 +0200 Original-Received: from localhost ([127.0.0.1]:60012 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwdcZ-0007ai-Qx for ged-emacs-devel@m.gmane.org; Fri, 17 Sep 2010 12:17:07 -0400 Original-Received: from [140.186.70.92] (port=55656 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Owdav-0006jq-23 for emacs-devel@gnu.org; Fri, 17 Sep 2010 12:15:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Owdao-0000ul-RR for emacs-devel@gnu.org; Fri, 17 Sep 2010 12:15:24 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:24166) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Owdao-0000uI-Jp for emacs-devel@gnu.org; Fri, 17 Sep 2010 12:15:18 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8HGFEa8004807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Sep 2010 16:15:16 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8HAb97v022968; Fri, 17 Sep 2010 16:15:13 GMT Original-Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 607493321284740051; Fri, 17 Sep 2010 09:14:11 -0700 Original-Received: from dradamslap1 (/10.159.227.209) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Sep 2010 09:14:10 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: ActWesh/XGnoLUs+TIecHtII9Oa9wQABweXA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 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:130335 Archived-At: > because "e" happens to be a predefined global variable with > dynamic-scoping semantics. Now for people who use such magic > numerical constants often (e.g. in the context of Calc), this > may seem like an obvious no-no, but for a poor theoretician > like me who uses "e" days-in-days-out to mean "expression", > not being able to reliably use "e" as a free variable of a > closure is a real trap. > > BTW, the worst of the two is `e' and AFAIK it only has a single use in > Emacs, which is as the initial value of the register "e" in > calculator.el. > > At least `pi' is used a few more times, and it is not let-bound > anywhere, so we could decide to make `pi' lexically-scoped > and it would apparently work OK, but `e' OTOH is let-bound at > many places, so it's not at all obvious that making it > lexically-scoped wouldn't introduce subtle bugs. Of course, > this idea of making `pi' and `e' lexically scoped itself depends > on how one would force lexical-scoping for a few special vars in > files compiled with dynamic-scoping; something which the > current lexbind doesn't support right now. I'll offer my view only once here - and no flames please. It is _ridiculous_ to ever have given such global vars (constants) these names in the first place. I said it long ago and repeat it now that everyone is trying to jump through fancy hoops to deal with this. It is sufficient to define global constants with long, clear names, and let any code that really wants to use short names bind vars locally to the constants. Just cut the cord and deprecate the old names. Don't create aliases to provide compatibility in this case - just bite the bullet (and yes, force 3rd-party code to do the same). It's too bad, but this was a horrible design decision made long ago, and it should just be dealt with summarily. `float-e' is a longer name, but it is silly - this is not about whether the value is a float. The name should say what the constant means/is - `math-e' or whatever. Even a longer name than that is good - it helps avoid conflicts. The name can also proclaim that the var is a constant: `math-constant-e' or whatever.