From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: e and pi Date: Fri, 17 Sep 2010 17:11:40 +0200 Message-ID: References: <8739t9xpt2.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1284736368 8721 80.91.229.12 (17 Sep 2010 15:12:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 17 Sep 2010 15:12:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 17 17:12:47 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 1OwccH-0002EZ-TC for ged-emacs-devel@m.gmane.org; Fri, 17 Sep 2010 17:12:46 +0200 Original-Received: from localhost ([127.0.0.1]:44595 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwccH-0002ZR-6r for ged-emacs-devel@m.gmane.org; Fri, 17 Sep 2010 11:12:45 -0400 Original-Received: from [140.186.70.92] (port=50359 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwcbN-00022o-Do for emacs-devel@gnu.org; Fri, 17 Sep 2010 11:11:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OwcbM-0005ly-6u for emacs-devel@gnu.org; Fri, 17 Sep 2010 11:11:49 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39542) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OwcbM-0005lR-2t for emacs-devel@gnu.org; Fri, 17 Sep 2010 11:11:48 -0400 Original-Received: from ceviche.home (vpn-132-204-232-179.acd.umontreal.ca [132.204.232.179]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o8HFBfm9012638; Fri, 17 Sep 2010 11:11:42 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 2A29E66289; Fri, 17 Sep 2010 17:11:40 +0200 (CEST) In-Reply-To: <8739t9xpt2.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 16 Sep 2010 18:54:17 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3624=0 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:130316 Archived-At: >> Can anyone think of a better solution? > I don't like the idea of `float-e' and `float-pi'. > What is the problem with dynamically scoping `e' and `pi'? If it's only > the compiler warning, we can give the compiler a whitelist of variables > not to complain about. It's not a question of compiler warning. It's a question of semantics. Let's take a classic example where lexical-scoping matters: currying. E.g. the following function (defun make-inc (n) (lambda (m) (+ n m))) means that (make-inc 3) returns a function which adds 3 to its argument: (let ((f (make-inc 3))) (funcall f 5)) should evaluate to 8. Now, this only works because "n" is statically scoped. So in the current lexbind branch (where e is defined as a global/dynamic variable), the below code would not do the same: (defun make-inc (e) (lambda (f) (+ e f))) 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. Stefan PS: Oddly enough, SML has a similar trap where "o" is predefined as the function-composition operator and "op" is a rarely used reserved keyword, and I think everyone agrees by now that these were bad decisions.