Re: e and pi

From:

Stefan Monnier

Subject:

Re: e and pi

Date:

Fri, 17 Sep 2010 17:11:40 +0200

User-agent:

Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> 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.