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: constant `e' Date: Thu, 8 Feb 2007 23:37:36 -0800 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1171006706 15809 80.91.229.12 (9 Feb 2007 07:38:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2007 07:38:26 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 09 08:38:19 2007 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.50) id 1HFQKn-0007bg-4y for ged-emacs-devel@m.gmane.org; Fri, 09 Feb 2007 08:38:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HFQKm-00015x-AC for ged-emacs-devel@m.gmane.org; Fri, 09 Feb 2007 02:38:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HFQKY-00012D-WF for emacs-devel@gnu.org; Fri, 09 Feb 2007 02:38:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HFQKX-000121-J3 for emacs-devel@gnu.org; Fri, 09 Feb 2007 02:38:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HFQKX-00011y-Cr for emacs-devel@gnu.org; Fri, 09 Feb 2007 02:38:01 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HFQKW-0001OX-Sb for emacs-devel@gnu.org; Fri, 09 Feb 2007 02:38:01 -0500 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l197bkVg019220 for ; Fri, 9 Feb 2007 00:37:46 -0700 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l197H69C029543 for ; Fri, 9 Feb 2007 00:37:46 -0700 Original-Received: from dhcp-amer-csvpn-gw1-141-144-67-35.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 2434947871171006659; Fri, 09 Feb 2007 00:37:39 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 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:66149 Archived-At: A minor whine - ignore if you don't agree. Single-character global variables are generally not such a great idea. In particular, they can easily occur as typographical errors and not be detected for a while. The variable `e', defined in `float-sup.el', has been around for a long time, but I wonder if it wouldn't be better to give it a different name in Emacs, because of the possibility of `e' occurring as a typo. [In fact, I wonder if much is gained in speed by defining it as a variable at all, instead of just using its definition of (exp 1) whenever its value is needed (or caching the value locally, when appropriate). I also wonder why `pi' is a defconst but `e' is a defvar.] `t' is similar, of course, but `t' as a typo is less surprising for anyone at all used to Lisp. `e' as a numerical constant is not used in most Emacs-Lisp code, so it is more likely that someone might be surprised by the effect of an `e' typo (once discovered). The position of `e' on many keyboards also makes it easy to hit when you mean to hit a numeral key such as `3', and, unlike `t', the type of `e' is numeric, so the value mismatch won't always lead to a type mismatch that might make the error more apparent. There are many other one-letter physical and mathematical constants. Fortunately, their names are not used as the names of Emacs constants and variables. `e' seems to be the exception. Even a two-letter name, such as `pi', is much, much less error prone than a one-letter name. Obviously, renaming `e' now would break existing code, but if others agreed, then we might plan to deprecate `e' over time, in favor of a longer name. Another possibility would be to change `e' to a function or macro, and deprecate the variable over time. In that case too I'd prefer a longer name than one character, but a one-character function or macro name is generally less error-prone than a variable name. As mentioned above, another approach (which I prefer, actually) would be to just drop `e' altogether and advise people to use (exp 1). Anyone needing to use `e' would be likely to know this definition, in any case. BTW, this comment in `float-sup.el' is ironic. It argues, itself, against the library's defining `e': ;; Careful when editing this file ... typos here will be hard to spot. ;; (defconst pi 3.14159265358979323846264338327 ;; "The value of Pi (3.14159265358979323846264338327...)") Perhaps that comment dated from some time (?) pre-Emacs 20 when `pi' was defined using explicit decimal notation, as in the line that follows it, and perhaps only mistyping numerals was meant, but I find it amusing when thinking about the possibility of `e' typos. Unfortunately, the effect is not confined to this library ("typos here") - `e' is a global name, and `float-sup.el' is preloaded. The best joke is not that self-referencing comment, but the fun someone would have trying to find all occurrences of variable `e' in the existing code, to rename them (and debugging missed or inappropriate renamings). Undefining it and seeing what happens would be one approach... Obviously not something to attempt before the release, in any case. ;-)