The variables +, -, *, and /

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

In fact, we did not blindly follow precedent in this case.  I remember
asking, at the time we were doing the Eval chapter, whether we should
flush these names in favor of something more mnemonic and more
standard-looking.  The feeling was that these things are for use by the
user at the keyboard and that they want to be very short.  Some users
have an interaction style that depends on these things very heavily.
Given that, these seemed like the one-character symbols that a user was
least likely to accidentally include in a program as a symbol, precisely
because they are so universally used as function names that they look
ugly as variables.  If we had been willing to postulate an Emacs-like
top-level for every implementation, we could have come up with some
different mechanism than the use of side effects on variables to save
the recent results, but at the time we felt that we had to allow for
simple but usable top-levels.  I'm not sure I'd make the same choice
today, but it's not one that look obviously crazy to me.

I think that by the time a user is playing with embedded languages, he
is not such a beginner and he had damned well better make friends with
packages.  That's what they are for, and I think they are a reasonably
good solution.  Note that you don't have to avoid using LISP in this
case, if *+/- is your only concern.  Just create a new package, use
LISP, and shadow those specific symbols.

-- Scott