Re: e and pi

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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