[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 8 Feb 2007 23:37:36 -0800
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. ;-)
Re: constant `e', Richard Stallman, 2007/02/09
- constant `e',
Drew Adams <=