The variables +, -, *, and /

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Fri,  6 Dec 85 03:30:43 EST
    From: Tim McNerney <TIM@MIT-MC.ARPA>

    I realize that there are ways of working around the problems caused by this
    unfortunate choice of names, but this is not the point.  I am appealing, not
    for seasoned Lisp hacker, but for the Lisp user experimenting with new
    languages who is not familiar with, for instance, the subtleties of creating
    packages which do not :use the LISP package.

Naive users should be taught how to program using reasonable techniques. 
There are recently dozens of examples of people who did langauges embedded in
another which were implemented as puns on primitive language semantics and then
had their respective jokes spoiled by changes to the language. The case that
comes immediately to mind are languages that claimed to be dynamically scopped
but which were in fact depended on their underlying language to be dynamic, so
when the underlying language became lexical, the embedded language became broken.
There are right and wrong ways to do embedded languages. People should not continue
to use broken techniques when workable ones exist.

    The Common Lisp language is riddled with historical relics which were
    preserved in the interest of making old programs like Macsyma have some hope
    of being ported to Common Lisp (an example of this is the separate function
    and value cell), but there is no reason to make the Top-Level Loop compatible
    with Maclisp and their descendants.  Furthermore, to reserve variable names
    which admittedly do not follow the *...* convention, which are side-effected
    by the Top-Level Loop, which are globally declared special, and which naive
    Lisp users are likely to try use in their programs, seems inexcusable.

System constants (eg, PI, MOST-POSITIVE-FIXNUM, ARRAY-RANK-LIMIT) are already in
that namespace even if they are treated slightly differently. Your naive users had
better know about these or they'll confuse themselves. Once they've learned about
these, a few more un-starred names is not unreasonable.

Besides, Lisp is a symbol-processing language. By that we mean that it's the token
itself, not the character string which is its print-name, which is of interest.
Allowing stars on the end of the symbol's printname to dictate the semantics of a 
variable is what would be inexcusable.

    If Common Lisp were not supposed to be an excellent language for developing
    new languages, I would not be nearly so disappointed.

The proposed solution (using packages) mentioned by all the respondents thus far
does not inhibit you from doing reasonable things. I don't know why you should be
disappointed. If you dislike packages as much as I, you should be pleased that they
offer a way for you to isolate yourself from the rest of the CL world and build 
your own personalized world out of symbols whose semantics, plist, value, etc will
be untarnished by CL's hairy mechanisms. It would be far less easy to hide a CL
embedded in any of the Scheme's I know of.

	    Tim McNerney
	    ICAD, Inc.

    P.S.  Incidentally, please, please, let us not stumble into another discussion
	  about the pros and cons of separate function and value cells.

	Date: Wed, 4 Dec 1985  11:13 EST
	From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>

	We thought brielfly about such issues ...

On the subject of amateur archiving, let me say that I find including another's message
at the end of a long message like this to be silly. It gives me the impression that my
Babyl file has been trashed and that somehow the boundary between two messages has 
disappeared. If I've gotten as far as reading to the point where this sort of included
message appears, I no longer need the context.