A modest proposal (long)

152 views
Skip to first unread message

Erann Gat

unread,
Feb 29, 2000, 3:00:00 AM2/29/00
to

I've been watching the recent threads on special variables, top-level
setq-s and the like, and I've come to the conclusion that the current
situation is badly broken. I have a proposal on how to fix it that I'd
like some feedback on.

The intractable problem is that beginners are chronically confused by
the fact that Lisp does not make an adequate syntactic distinction
between two completely different ways of binding variables. Imagine
you are reading some code and you encounter the following two functions:

(defun foo (x) (blarg x))

(defun baz (y) (blarg y))

Do FOO and BAZ do the same thing? Well, they might or they might not.
It depends. It depends on whether X or Y have been DEFVARed. It depends
on whether there are any free references to X or Y in any function called
by BLARG. It depends on whether you are trying to write thread-safe code.
It depends on whether performance differences matter. It depends on whether
your code is interpreted or compiled. And if you want to explain the
reasons it depends on all these things you have to start talking about
the differences between symbols and variables, what bindings are, and
that there's nothing at all special about "special" variables, it's just
an ancient piece of Lisp terminological baggage that means nothing more
than "dynamic scope."

A beginner's initiation into this state of affairs invariably comes when
he or she one day as an expedient types (defvar x 1) and then spends the
rest of the day (or week) trying to figure out why her code is suddenly
exhibiting mysterious bugs. The admonition to always use *...* notation
for DAFVARed variables is a temporary fix, but it generally takes a very
long time for a typical programmer to wrap their brains around what is
really going on.

The problem is pervasive and subtle. Consider:

(funcall (lambda (x y) (lambda () ... x ... y ...)) 1 2)

Does this return a lexical closure over X and Y? Well, it might, or it
might not. It depends.

Now, this has not been much of an issue because artificially separating
the name spaces of lexical and dynamic variables using the *...* convention
generally works to keep the problem at bay. But the trouble is that this
solution only works if you use it, and you can only use it if you are
aware of it. And even if you are aware of it, your collaborator might
not be. *You* might not have DEFVARed X, but how do you know that Joe
didn't?

The solution to this problem is to change the language so that the
distinction between dynamic and lexical bindings is locally manifested.
This is technically simple, but politically complex because it means
either adding some kind of lexical declaration or getting rid of pervasive
SPECIAL declarations (e.g. getting rid of DEFVAR, (PROCLAIM (SPECIAL ...))
etc.) My personal preference is the latter. Top-level declarations that
radically change the semantics of code in ways that are not lexically
apparent are EVIL!

Even local special declarations are IMO evil. The semantics of a piece
of code ought not to depend on forward references. It's also very much
against the spirit of a declaration. Declarations are for providing extra
information for the compiler. They are not for changing the semantics of
the program. It should be possible to remove all declarations without
changing anything about the program except how fast it runs.

The solution is obvious. Special variables are nothing more than the
symbol-value slot of some symbol. Why not make that simple fact manifest
itself in the syntax? For example:

(let ( (x 1) ; A lexical binding
((symbol-value x) 2) ) ; A dynamic binding

While we're at it we could fold in the binding of multiple values and
destructing into one uniform syntax:

(superlet ( (x 1) ; A lexical binding (guaranteed)
((symbol-value x) 2) ; == (let ((x 2)) (declare (special x))
((values a b c) (foo)) ; == (multiple-value-bind (a b c) (foo)
((values a (symbol-value b) c) (baz))
; As above, but with (declare (special b))
((a b c) (foo)) ) ; A DESTRUCTING-BIND

A simple reader macro helps make things a lot less wordy:

$x == (symbol-value 'x)

So now we can write:

(let ( (x 1) ($y 2) ) ; X is a lexical binding, Y is a dynamic binding

This would work at top-level too:

(setf $x 1) ; Set the global X with no warnings and no semantic ambiguity
(setf x 1) --> Warning! No lexical variable named X visible here. Setting
$X instead.

To implement this proposal completely requires the cooperation of Lisp
implementors because you have to change the way lambda lists are
processed. But once that's done you can write (lambda (x $y) ...)
instead of (lambda (x y) (declare (special y)) ...), or
(multiple-value-bind (x $y) (foo) ...) instead of (multiple-value-bind
(x y) (foo) (declare (special y)) ...) or (defun foo (x $y) ...) instead
of (defun foo (x y) (declare (special y)) ...)

As a prototype I have implemented a macro called BIND that works as
described above. BIND binds lexical and dynamic variables, and handles
multiple values and destructuring. It also uses a paren-less LOOP-like
syntax. I present it as both an illustration of how simple my proposal
would be to implement properly, and as an illustration of how easy it is
to change Lisp completely within the standard.

The syntax for BIND is:

(BIND var [=] value [and] ... in &rest body)

var : symbol | (symbol-value symbol) | (values var var ...) | list

Keywords in square brackets are optional.

Example: (BIND x = 1 and (z ($y) q) = (foo) and (values $a b c) = (baz) in ...)

expands to:

(let ( (x 1) )
(destructuring-bind (z (y) q) (foo)
(declare (special y))
(multiple-value-bind (a b c) (baz)
(declare (special a))
...

I conjecture that beginners at least will find BIND easier to deal with
than the things it replaces.

Erann Gat
g...@jpl.nasa.gov
---


(set-macro-character #\$
(lambda (s c)
(declare (ignore c))
(if (whitespacep (peek-char nil s))
'|$|
`(%symval ,(read s))))
t)

(defmacro %symval (x) `(symbol-value ',x))

(defun process-vartree (vl)
(let ( (specials '()) )
(setf vl
(iterate loop1 ( (v vl) )
(cond ( (atom v) v )
( (eq (car v) '%symval)
(push (second v) specials)
(second v) )
(t (cons (loop1 (car v)) (loop1 (cdr v)))))))
(values vl specials)))

(defmacro bind (&rest forms)
(cond ( (null forms) (error "Missing IN keyword") )
( (eq (car forms) 'in)
`(progn ,@(cdr forms)) )
( (eq (car forms) 'and)
`(bind ,@(cdr forms)) )
(t (let ( (var (pop forms))
(val (pop forms)) )
(if (eq val '=) (setf val (pop forms)))
(cond
( (atom var)
`(let ( (,var ,val) ) (bind ,@forms)) )
( (eq (car var) '%symval)
(setf var (second var))
`(let ( (,var ,val) )
(declare (special ,var))
(bind ,@forms)) )
( (eq (car var) 'values)
(receive (vars specials) (process-vartree (cdr var))
`(multiple-value-bind ,vars ,val
(declare (special ,@specials))
(bind ,@forms))) )
(t (receive (vars specials) (process-vartree var)
`(destructuring-bind ,vars ,val
(declare (special ,@specials))
(bind ,@forms)))))))))

#|
; Example:
(defun baz () (values 1 2 3 4))

(defun foo ()
(declare (special x y))
(list x y $z $w)) ; Look Ma, no warnings!

(setf x nil y nil z nil w nil)

; Sample output:
? (foo)
(NIL NIL NIL NIL)
? (bind x = 1 in (list x (foo)))
(1 (NIL NIL NIL NIL))
? (bind $x = 1 in (list x (foo)))
(1 (1 NIL NIL NIL))
? (bind $x = 1 x = 2 in (list x (foo)))
(2 (1 NIL NIL NIL))
? (bind (x $y z $w) '(1 2 3 4) in (list x y z w (foo))) ; destrucuring-bind
(1 2 3 4 (NIL 2 NIL 4))
? (bind (values x $y z $w) (baz) in (list x y z w (foo))) ; multiple-value-bind
(1 2 3 4 (NIL 2 NIL 4))
?
|#

Erik Naggum

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
* Erann Gat

| *You* might not have DEFVARed X, but how do you know that Joe didn't?

it seems to me that this the fundamental question. the answer lies in
the implementation's excellence in implementing the function `describe'
and any other environment-querying functions.

however, there _is_ something we can and should do: add explicit support
for retrieving this important piece of information about a symbol, apart
from the rather obvious user interface issues like querying the system
when at a symbol name in Emacs. the compiler and the interpreter could
also be asked to produce warnings about special variables for those who
need them. (I'd favor declaring variables special locally as a nice way
to document the known special effects and also silence such warnings.)

removing special variables because they confuse a few people is a typical
"modern" reaction to the lack of diligence and effort that "modern" users
are no longer expected to expend in learning anything. this is simply a
beginner's issue. Common Lisp used to cater to experienced programmers
at the cost of having to learn it, like a _skill_, something people of
reasonable competence levels would _value_. such is of course terribly
politically incorrect in this day and age, where blathering idiots get to
vote as many times as they can by virtue of forgetting the question and
anyone with any experience at all is considered prejudiced by virtue of
not answering all questions up for vote with a blank stare.

I vote that Common Lisp remain a language that needs to be learned and
studied, and instead focus our attention on stuff that actually affects
users of all categories much more than this trifling issue, like being
compatible with the notion in languages with which we would like to
communicate of what constitutes a symbol name: the actual, literal
sequence of characters (dollar signs included), not some case-mangled
version of same.

I also vote that somebody write "the complete idiot's guide to special
variables" instead of proposing silly language changes.

| $x == (symbol-value 'x)

I think "Common Perl" would be a good name for your modified language,
with syntax in macros and equal signs and all. yuck.

#:Erik

Janos Blazi

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
As changing the language is a long term project at best, it really would be
helpful if somebody wrote a guide mentioned in another response (though I
should choose a different title :) .)
I must admit that I for example do not understand these things well. Now it
is easy to expect others to do something for you but on the other hand this
should have to be done by someone who is an expert. And it should be written
in a simple language (as simple as possible) with all terms carefully
defined and with a *lot* of examples.

Janos Blazi


Erann Gat <g...@jpl.nasa.gov> schrieb in im Newsbeitrag:
gat-290200...@milo.jpl.nasa.gov...


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Keke Abe

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
In article <gat-290200...@milo.jpl.nasa.gov>, g...@jpl.nasa.gov (Erann Gat) wrote:

> The problem is pervasive and subtle. Consider:
>
> (funcall (lambda (x y) (lambda () ... x ... y ...)) 1 2)
>
> Does this return a lexical closure over X and Y? Well, it might, or it
> might not. It depends.

It depends... but have you ever worried about x minght be special when
you write the code like above? The chance are so remote that I think
trying to eliminate it (by changing CL) is overkill.

>
> Now, this has not been much of an issue because artificially separating
> the name spaces of lexical and dynamic variables using the *...* convention
> generally works to keep the problem at bay. But the trouble is that this
> solution only works if you use it, and you can only use it if you are
> aware of it. And even if you are aware of it, your collaborator might
> not be.

You can't force anyone not to write bad code by language spec alone.
(In this case, however, you can search DEFVAR form in the code?)

**

I don't think this is not a CL specific problem. And programmers
have already been advised to avoid the usage of 'global' variables
with indefinite scope unless it is necessary.

Is there anything particularly dangerous when a beginner equates
CL's special variables to global vars in other languages?


regards,
abe

Erik Naggum

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
* Keke Abe

| Is there anything particularly dangerous when a beginner equates
| CL's special variables to global vars in other languages?

I can't answer for Erann, but my take on this is that beginners who get
confused about this will remain confused for a few days, and then get it
or get over it, as in: not worrying about it even if they don't get it.

if we change the semantics of the language from what said confused people
will find described in textbooks and other reference materials and when
searching the net, the number of days of confusion can only increase, not
the least because half the vendors will think this is a lame idea and not
implement it, and the other half will do it better than the lame code and
so the only thing we will succeed in is in destroying a very powerful
mechanism in Common Lisp that every other language is sadly lacking:
transparent, safe, and convenient global, dynamic variables. all for the
purported, but obviously unrealizable benefit of reducing the number of
confused people and their posting frequency to comp.lang.lisp.

still, it would be nice if we had some simple programmatic access to the
specialness of a symbol. this would have been covered by the environment
access functions that were not included in the standard.

#:Erik

William Deakin

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
Erik wrote:

> ...but my take on this is that beginners who get confused about this will


> remain confused for a few days, and then get it or get over it, as in: not
> worrying about it even if they don't get it.

As a beginner, this is my experience. I'm in the not worrying about it (or is
that denial ;) stage. I found that this is one of those things that when I read
the description of special vs dynamic vs local caused my head to hurt, but in
practice has caused me little pain [1].

[...elided excellent reasons for not changing the sematics of the language...]

> still, it would be nice if we had some simple programmatic access to the
> specialness of a symbol. this would have been covered by the environment
> access functions that were not included in the standard.

This IMHO is a good idea.

Best Regards,

:) will

[1] Except in the case when I was writing some macros with cmucl. But this
maybe more of an issue with the implementation declaring all top level
variables special. More and better descriptions of this are elsewhere.

Tim Bradshaw

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
I think I agree with Erik about this. There is clearly a problem here
in principle. In practice I have *very* seldom been bitten by it, and
I'd be loth to change the language to make it `easier' for people at
the cost of adding something like the BIND macro you suggest (at
least, not with the syntax you suggest, which I have much the same
reaction to as Erik I'm afraid). I'm also very loth to use up one of
the extremely small number of available characters to be a read-macro
for something like this.

I'd also like to gratuitously point out that your technique doesn't
actually solve the whole problem: symbol-macros can mean that what
looks like an innocent variable is actually something entirely
different.

I think a much more useful meta-solution to this problem is better
environmental information, and a compiler MOP and/or code walker.
Given that I can instrument the compiler in such a way that it will
warn me if it ever sees a special variable that does not adhere to
whatever naming convention I choose, or in general check any other
thing I like about the code I'm compiling.

And this solution has the advantage that it's useful for other stuff
too!

--tim

Joe Marshall

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
g...@jpl.nasa.gov (Erann Gat) writes:

> Now, this has not been much of an issue because artificially separating
> the name spaces of lexical and dynamic variables using the *...* convention
> generally works to keep the problem at bay. But the trouble is that this
> solution only works if you use it, and you can only use it if you are
> aware of it. And even if you are aware of it, your collaborator might
> not be. *You* might not have DEFVARed X, but how do you know that Joe
> didn't?

I didn't! Honest!

> The solution to this problem is to change the language so that the
> distinction between dynamic and lexical bindings is locally manifested.

I agree that the distinction sohuld be locally manifest, but I don't
think we need a radical change to the language to ensure this.

A little help from the programming environment would go a long way to
solving the problem. Wrapping '*' around a variable is the
de-facto standard for special variables. If the compiler issued a
warning when you declared or used a special variable without '*', or
if you declared or used a non-special (lexical) variable _with_ a '*',
it would probably solve the bulk of the problem without introducing
changes to the language.

~jrm

Sam Steingold

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
>>>> In message <31608864...@naggum.no>
>>>> On the subject of "Re: A modest proposal (long)"
>>>> Sent on 01 Mar 2000 08:01:09 +0000

>>>> Honorable Erik Naggum <er...@naggum.no> writes:
>>
>> still, it would be nice if we had some simple programmatic access
>> to the specialness of a symbol.

in CLISP:
(defvar x)
(system::special-variable-p 'x) ==> T

--
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
My other CAR is a CDR.

Robert Posey

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to

Tim Bradshaw wrote:
>
> I think I agree with Erik about this. There is clearly a problem here
> in principle. In practice I have *very* seldom been bitten by it, and
> I'd be loth to change the language to make it `easier' for people at
> the cost of adding something like the BIND macro you suggest (at
> least, not with the syntax you suggest, which I have much the same
> reaction to as Erik I'm afraid). I'm also very loth to use up one of
> the extremely small number of available characters to be a read-macro
> for something like this.

I have to conditionally agree with Erik (someone stop me, Please!!) if
their experience is representative of general programing experiences.
Structure changes in well established languages should only be made based
as hard of data as possible. Before you change a basic feature like this,
make sure the problem exists for programers or program teams who have
at least 2-3 months of real experience ( not classes, or individual projects).
For problems that mostly only effect beginners, more environmental
information is both easier to implement and serves an educational
purpose. I personnely(based on C, C++ and assembly lang exp) would
find a describe function that would provide an complete description
of the scope and type of a variable at the CURRENT time to be more
useful. It would also be very nice, if the development system
would list all of the variables visible at a given level. While
I find *name* notation a little strange, hopefully there are not
too many development teams of any size that do not have enforced
naming standards for all variables and functions.


BTW does anyone
know of a reference that has a GOOD description of hopefully
general methods to come up with a naming standard for symbols,
variables, functions etc.? Is there something approaching a standard.

My best coding experience was one in C, where the name of a variable or
function told you in what file it was define, whether it was global,
or a constant. It didn't include type, but that wasn't too much of
a problem since almost every thing was an Integer, and on the
DSP we were using short, int, long integer were all 32 bits and
strings only existed in 2 out of 200 files.

Muddy

Robert Monfera

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to

Robert Posey wrote:

> My best coding experience was one in C, where the name of a variable

> or function told you in what file it was define[d]

It would astonish and maybe convert even the most avid advocates of
Hungarian coding.

Robert

Pierre R. Mai

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
Robert Posey <mu...@raytheon.com> writes:

> BTW does anyone
> know of a reference that has a GOOD description of hopefully
> general methods to come up with a naming standard for symbols,
> variables, functions etc.? Is there something approaching a standard.

I don't think there are general standards, apart from:

- Use * to surround global special variables
- Use + to surround global constants
- Let yourself be guided by the (newer parts of the) ANSI CL standard
for ideas on how to name accessors, functions and variables.

> My best coding experience was one in C, where the name of a variable or

> function told you in what file it was define, whether it was global,
> or a constant. It didn't include type, but that wasn't too much of
> a problem since almost every thing was an Integer, and on the
> DSP we were using short, int, long integer were all 32 bits and
> strings only existed in 2 out of 200 files.

Well, since every useful (Lisp) development environment will include
functions to locate the corresponding definition, encoding filenames
in the names isn't very useful nowadays. Since in CL objects are
typed and (normally) not variables, it doesn't make much sense to
include type information in the name either.

Regs, Pierre.

--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]

Robert Posey

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to

"Pierre R. Mai" wrote:


>
> Robert Posey <mu...@raytheon.com> writes:
>
>
> Well, since every useful (Lisp) development environment will include
> functions to locate the corresponding definition, encoding filenames
> in the names isn't very useful nowadays. Since in CL objects are
> typed and (normally) not variables, it doesn't make much sense to
> include type information in the name either.

That's if you are reviewing the code using the development system, that
is often not the case where I work, or I suspect on many large development
teams.

Muddy

wne...@my-deja.com

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
In article <31608864...@naggum.no>,

Erik Naggum <er...@naggum.no> wrote:
> * Keke Abe
> | Is there anything particularly dangerous when a beginner equates
> | CL's special variables to global vars in other languages?
>
> I can't answer for Erann, but my take on this is that

> beginners who get confused about this will remain confused for
> a few days, and then get it or get over it, as in: not worrying
> about it even if they don't get it.

It's not just a beginner problem. The program
(DEFUN FOO (X) (BAR X))
(DEFVAR X)
means something different from
(DEFVAR X)
(DEFUN FOO (X) (BAR X))
And if the DEFVAR is in one file, and the DEFUN is in another,
then the semantics change silently depending on what order
you compile them in. You wrote

> transparent, safe, and convenient global, dynamic variables

but I'd say this is a design flaw that makes them not particularly
safe.

I don't think it's a bad enough problem to justify changing the
language to solve it, but it's a real problem, even for real,
experienced programmers. I recently finished renaming
most of the special variables in the SBCL implementation of
Common Lisp to use the *FOO* convention. It was a considerable
amount of work. And even for the variables which use this convention,
I still have to worry about subtly breaking something a la
(DEFVAR *FOO*)
(DEFUN BAR (..)
(LET ((*FOO* (..)))
(BLETCH *FOO*)
(ZUT)
;; Don't move the DEFVAR to here, or you will lose.
(DEFUN ZUT () ; which I hope isn't something obscene in Italian:-)
(IF *FOO* (ZUT1) (ZUT2)))
when *FOO*, BAR, and ZUT are defined in different files and
the order of compilation might be rearranged. I'd need to be
fairly unlucky to rearrange just the right things in just the right
way to silently break something like this, but it could happen.

By and large, Common Lisp does a good job of letting you define things
in any order, which is a good thing. By and large, when you can't
define things in any order (e.g. DEFCLASS) at least it gives you
an error, which is a good thing. But the problem I described just
above won't give you an error in any implementation I'm aware of,
which is nasty.

(By the way, I've considered making SBCL issue STYLE-WARNINGs
for any SPECIAL use of non-*FOO*-style symbols, and any non-SPECIAL
use of *FOO*-style symbols, to detect problems like this. But I'm
a little uncomfortable embedding informal naming conventions in the
compiler, so I've avoided doing this so far. Does anyone have
any opinions on whether such STYLE-WARNINGs would be The Right
Thing?)

> still, it would be nice if we had some simple programmatic

> access to the specialness of a symbol. this would have been


> covered by the environment access functions that were not
> included in the standard.

Yes, I also really wish there was a standard way to
query "is symbol FOO special?" And "what's the value of the
optimization property BAR?" too..

Bill Newman


Sent via Deja.com http://www.deja.com/
Before you buy.

Pierre R. Mai

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
Robert Posey <mu...@raytheon.com> writes:

> > Well, since every useful (Lisp) development environment will include
> > functions to locate the corresponding definition, encoding filenames
> > in the names isn't very useful nowadays. Since in CL objects are
> > typed and (normally) not variables, it doesn't make much sense to
> > include type information in the name either.
>
> That's if you are reviewing the code using the development system, that
> is often not the case where I work, or I suspect on many large development
> teams.

How do you review the code? On printed paper?

Erann Gat

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
In article <ey3ln42...@cley.com>, Tim Bradshaw <t...@cley.com> wrote:

> I think I agree with Erik about this. There is clearly a problem here
> in principle. In practice I have *very* seldom been bitten by it, and
> I'd be loth to change the language to make it `easier' for people at
> the cost of adding something like the BIND macro you suggest (at
> least, not with the syntax you suggest, which I have much the same
> reaction to as Erik I'm afraid). I'm also very loth to use up one of
> the extremely small number of available characters to be a read-macro
> for something like this.

I see I have not made myself clear.

The $ macro is optional. So is the BIND macro. The core of my
proposal is to move the specification of dynamic bindings out of
the declarations and into the lambda list. It's a 100% backwards-
compatible change, and it doesn't change the semantics of the language
at all. It's also very much in the spirit of Common Lisp. All I am
saying is that we should extend lambda-list syntax to allow variables
whose names are lists beginning with SYMBOL-VALUE (or SPECIAL or
DYNAMIC, I don't really care which keyword we choose). It's much
like extending the syntax of function names to include lists whose
first element is SETF.

BTW, all the keywords in the BIND macro are optional except IN, so you
can dispense with all the = signs and ANDs and just write:

(bind x 1 (symbol-value q) 2 (values y z) (foo) in ...)

It's also pretty simple to change BIND to use parens instead of a
keyword to separate the bindings from the body:

(bind (x 1 (symbol-value q) 2 (values x z) (foo)) ...)

or:

(bind ( (x 1)
((symbol-value q) 2) ; implied (declare (special q))
((values y z) (foo)) ; multiple-value-bind
((a (symbol-value b) c) (baz)) ) ; destructuring (with a special)
...

Without BIND this code becomes:

(let ( (x 1)
(q 2) )
(declare (special q))
(multple-value-bind (y z) (foo)
(destructuring-bind (a b c) (baz)
(declare (special b))

Personally, I think:

(bind x 1 $q 2 (values y z) (foo) (a $b c) (baz) in ...

is a win. Notice also that you can implement this without a reader macro.
BIND could simply declare special those variables whose print names start
with $, or whose print names start and end with *, thus:

(bind ( (x 1) (*y* 2) ) ; *Y* is automatically declared special

We are already using a typographical convention to distinguish lexical and
special variables. We already know that we get into trouble when we don't
adhere to that convention. Why not move the burden of applying that
convention from the programmer to the compiler?

I also wonder how many of you BIND haters are also LOOP haters. I am
really beginning to worry that people have lost sight of the fact that
an S-expression with just one level of parens is still an S-expression.

> I'd also like to gratuitously point out that your technique doesn't
> actually solve the whole problem: symbol-macros can mean that what
> looks like an innocent variable is actually something entirely
> different.

But symbol macros can only be established with lexical scope, so if
there is a symbol macro it must be lexically manifested. Global symbol
macros would be truly problematic. In fact, this is the problem with
DEFVAR. It essentially establishes a global symbol macro that replaces
all occurrences of X with (symbol-value 'x), except that this happens
silently, and there's no way to undo it.

E.

Tim Bradshaw

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
* Erann Gat wrote:

> I see I have not made myself clear.

No, I understood what you meant. I just want to know if this is a
problem *in practice*[1], and if it is to think out a fix. Common Lisp
is a pragmatic language and I don't think that changes to fix things
that aren't in practice an issue are needed. That's why we don't have
hygienic macros, after all.

I also think that if you are going to make a change to the language
like this, you should think it out a good deal first. For instance my
suggestion of better environmental access would enable you to detect
these kinds of problems yourself, but it would also enable a whole
bunch of other cool stuff.

If you want to stick to souping up lambda lists, why just fix this one
issue? Why not let general declarations be in there? Step back from
the problem.

> The $ macro is optional. So is the BIND macro. The core of my
> proposal is to move the specification of dynamic bindings out of
> the declarations and into the lambda list. It's a 100% backwards-
> compatible change, and it doesn't change the semantics of the language
> at all.

But, if it becomes standard, it *does* make every current conforming
implementation non-conforming, and incurs a cost on every vendor who
wishes to remain conforming. That is another reason to consider
changes really carefully, and, I think, another reason to make changes
that add as much value as possible rather than ad-hoc fixes to
individual perceived problems.

> But symbol macros can only be established with lexical scope, so if
> there is a symbol macro it must be lexically manifested. Global symbol
> macros would be truly problematic. In fact, this is the problem with
> DEFVAR. It essentially establishes a global symbol macro that replaces
> all occurrences of X with (symbol-value 'x), except that this happens

> silently, and there's no way to undo it.

DEFINE-SYMBOL-MACRO establishes global symbol macros. They are
shadowed by bindings however.

--tim

[1] All I can say is that, for me, this has not been a problem, and
people I've taught and worked with have not reported it as a problem.
But I can't speak for any very wide community.

Robert Posey

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to

"Pierre R. Mai" wrote:
>
> Robert Posey <mu...@raytheon.com> writes:
>
> > > Well, since every useful (Lisp) development environment will include
> > > functions to locate the corresponding definition, encoding filenames
> > > in the names isn't very useful nowadays. Since in CL objects are
> > > typed and (normally) not variables, it doesn't make much sense to
> > > include type information in the name either.
> >
> > That's if you are reviewing the code using the development system, that
> > is often not the case where I work, or I suspect on many large development
> > teams.
>
> How do you review the code? On printed paper?

Usually, its sent as a text file and I review it as a separate file on
a PC, in a code highlighting editor. So there is no way for the system
to know data from other files. This is partly a result of using Ada, and
old very limited tools. Since we are switching to C/C++, hopefully we will
start using smart tools. So I have zero experience reviewing other people's
code, using reasonable tools. My LISP coding experience is so far simply
class work or playing around, and is pretty limited at the moment. Another
problem is that many programs have classified code on them, which means that
some small part of the code is classified. What I work on is not classified,
so I often have limited access. They are starting to use Green hill compilers
and Vxworks so I hope they will support better collaboration, but I wouldn't
be surprised to see massive resistance to using an advanced features. However,
I still think that you are going to run into problems if you don't use
structured
names, it seems so much easier to read the code that way. Its a pain to always
have to click on every symbol to find out what it really means.

Muddy

Erik Naggum

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
* Erann Gat

| I see I have not made myself clear.

I see no evidence of that. I think we have a fairly good understanding
of your issue. all the silly syntax detracted from its delivery, but
you've been clear enough.

| We are already using a typographical convention to distinguish lexical
| and special variables. We already know that we get into trouble when we
| don't adhere to that convention. Why not move the burden of applying
| that convention from the programmer to the compiler?

because we would want to make our own conventions in code where it is
safe to make them. and people don't _actually_ get into trouble in the
first place, except the first few days they are confused about this.

| I also wonder how many of you BIND haters are also LOOP haters. I am
| really beginning to worry that people have lost sight of the fact that
| an S-expression with just one level of parens is still an S-expression.

no need to worry about that. I like loop, I don't if*, and I don't like
your bind or any of the numerous other _gratuitous_ syntax-heavy ideas
people seem to get with an alarming regularity whenever they see a need
for some miniscule improvement to the language. it's as if they don't
like simple syntax to begin with, and rush to solve any semantic issue
with syntax. I find this disturbing, but nonetheless indicative of
something much more important: the language changers don't really grok
Common Lisp.

| But symbol macros can only be established with lexical scope, so if
| there is a symbol macro it must be lexically manifested. Global symbol
| macros would be truly problematic.

take a look at define-symbol-macro some day and weep, then. I love the
fact that we have global symbol macros! I also love the fact that we
have constants, which also causes pervasive differences in behavior, and
there's no truly established convention for them. I happen to think that
special variables is one of Common Lisp's truly great idea. what I want,
in response to your "it's EVIL!" is a programmatic means to query the
system for the status of a symbol. `describe' and friends help me as a
user who gawks at the screen, but that is clearly insufficient.

again, there is a need to change the language to make it more amenable to
beginners and experienced users alike: unlike all other languages now in
current and widespread use, Common Lisp violates the notion that what you
see is what you get with respect to the _names_ of the symbols. if
symbol-value is such a problem for beginners that it needs language-smith
attention, wouldn't you be interested in solving a _real_ problem that
would have far-reaching consequences for our interoperability with other
languages, other textbooks, other people? it's not a question of case,
it's a matter of making (setf (readtable-case *readtable*) :preserve)
work the way people _actually_ expect it to. think about it. please.

#:Erik

Erik Naggum

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
* Bill Newman

| It's not just a beginner problem. The program
| (DEFUN FOO (X) (BAR X))
| (DEFVAR X)
| means something different from
| (DEFVAR X)
| (DEFUN FOO (X) (BAR X))
| And if the DEFVAR is in one file, and the DEFUN is in another, then the
| semantics change silently depending on what order you compile them in.

I maintain that this is a beginner problem, only. real Lisp programmers
don't call their global variables "X". real Lisp programmers use
packages if they want their symbols to stay of other people's face. real
Lisp programmers know about unintern, too.

| I'd say this is a design flaw that makes them not particularly safe.

it's a design flaw to you because your notion of safe is wrong.

| (By the way, I've considered making SBCL issue STYLE-WARNINGs for any
| SPECIAL use of non-*FOO*-style symbols, and any non-SPECIAL use of
| *FOO*-style symbols, to detect problems like this. But I'm a little
| uncomfortable embedding informal naming conventions in the compiler, so
| I've avoided doing this so far. Does anyone have any opinions on whether
| such STYLE-WARNINGs would be The Right Thing?)

I have already said what I think is the right thing here: demand that
there be lexically apparent declarations that reiterate the special
status of symbols so declared globally. lacking such a declaration, you
might issue a style-warning for free variables even if you know they are
globally declared special. it will lead to slightly more verbose code,
but the excuse to be making invisible, pervasive changes would go away.

| Yes, I also really wish there was a standard way to query "is symbol FOO
| special?" And "what's the value of the optimization property BAR?" too..

precisely, and this is the _only_ problem worth solving as I see it.

#:Erik

Erann Gat

unread,
Mar 1, 2000, 3:00:00 AM3/1/00
to
In article <31609426...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> | But symbol macros can only be established with lexical scope, so if
> | there is a symbol macro it must be lexically manifested. Global symbol
> | macros would be truly problematic.
>
> take a look at define-symbol-macro some day and weep, then.

You're right. I overlooked define-symbol-macro. I'm not weeping, but
I am shuddering.

> I love the fact that we have global symbol macros!

What do you use them for?

> I happen to think that
> special variables is one of Common Lisp's truly great idea.

I agree. The problem is not special variables. The problem is the
way you tell Lisp which variables you want to make special and which
you don't.

> what I want,
> in response to your "it's EVIL!" is a programmatic means to query the
> system for the status of a symbol. `describe' and friends help me as a
> user who gawks at the screen, but that is clearly insufficient.

The issue is not just one of querying. It's also one of control. There's
no way to undo the effects of a defvar short of uninterning the symbol.

> again, there is a need to change the language to make it more amenable to
> beginners and experienced users alike: unlike all other languages now in
> current and widespread use, Common Lisp violates the notion that what you
> see is what you get with respect to the _names_ of the symbols.

Maybe it would help to review the distinction between a variable and a
symbol (and the name of a symbol) just to make sure we are all on
the same page. Variables, symbols, and names are all different.
For example, here we have three (lexical) variables, but only two
symbols, and only one name:

(lambda (x) (lambda (x) (lambda (foo::x) ...

(Actually, we have three variables ONLY if X has not been DEFVARed.
If X has been defvared then we only have two variables.)

When you bind a lexical variable you make a new variable. When you
bind a special/dynamic variable you make a new binding for an existing
variable.

Specialness can be associated with variables (via SPECIAL declarations)
or with symbols (via DEFVAR) but NOT with names. Once specialness has
been associated with a symbol, it is no longer possible to create new
variables using that symbol, only new bindings for the (one) special variable
associated with that symbol (also known as the symbol's symbol-value).

The point is that none of this has anything to do with symbol names.
In fact, you can make examples using symbols that don't even have names:

(defmacro weird-lambda (&body body)
(let ( (arg1 (make-symbol ""))
(arg2 (make-symbol "")) )
`(lambda (,arg1 ,arg2) (declare (special ,arg1)) ...

Here there is one lexical binding and one dynamic binding. They are
associated with two uninterned symbols, neither of which has a name!

Here's an even more pathological example:

(progn
(defvar #1=#.(make-symbol "") 1)
(defun #1# () #1#)
(funcall (lambda (#1#) (#1#)) 2))

This wouldn't work in Scheme ;-)

> if symbol-value is such a problem for beginners that it needs language-smith
> attention, wouldn't you be interested in solving a _real_ problem that
> would have far-reaching consequences for our interoperability with other
> languages, other textbooks, other people?

I thought that's what I was doing, but it seems I still have not made
myself clear. You seem to think that I am saying that the problem is
the existence of dynamic variables and symbol-value. I'm not saying that
at all. What I am saying is that the way things currently stand, when
you write 'X' you can't in general know whether what you've
written is a reference to a stack frame or a slot in an object on the heap.
And, in fact, as you yourself pointed out the meaning of X can change
over time if you are running interpreted. IMO that's bad.

> it's not a question of case,
> it's a matter of making (setf (readtable-case *readtable*) :preserve)
> work the way people _actually_ expect it to. think about it. please.

It would help if you would stop talking in riddles. I honestly have no
idea what you mean.

? (setf (readtable-case *readtable*) :preserve)
:PRESERVE
? 'foo
foo
? 'foO
foO
? 'FOO
FOO
?

Works the way I'd expect it to.

E.

wne...@my-deja.com

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
In article <31609431...@naggum.no>,

Erik Naggum <er...@naggum.no> wrote:
> * Bill Newman
> | It's not just a beginner problem. The program
> | (DEFUN FOO (X) (BAR X))
> | (DEFVAR X)
> | means something different from
> | (DEFVAR X)
> | (DEFUN FOO (X) (BAR X))
> | And if the DEFVAR is in one file, and the DEFUN is in another, then
the
> | semantics change silently depending on what order you compile them
in.
>
> I maintain that this is a beginner problem, only. real Lisp
> programmers don't call their global variables "X". real Lisp
> programmers use packages if they want their symbols to stay
> of other people's face. real Lisp programmers know about
> unintern, too.

I don't think I'm going to be able to convince you of matters of taste
here. (I've never seen anyone else do it.:-) But perhaps I can at
least illustrate that there are more things in heaven and earth than
are dreamt of in your philosophy. (Or, in software engineering as
in quantum mechanics, the universe is not only stranger than we imagine,
it is stranger than we can imagine.)

The programmers who wrote the Python compiler (part of CMU CL,
available at http://www.cons.org/cmucl/) weren't beginners. But
they put somewhat over 10K lines of Common Lisp into the "C"
package (the compiler). And they defined special variables with
names like
C::TOP-LEVEL-LAMBDA-MAX
C::NO-LOADS
C::PACK-OPTIMIZE-SAVES
C::PACK-SAVE-ONCE
C::MAX-OPTIMIZE-ITERATIONS
C::PACK-ASSIGN-COSTS
C::VM-SUPPORT-ROUTINES
C::PRIMITIVE-TYPE-SLOT-ALIST
C::NO-COSTS
C::SYSTEM-CONSTANTS
I'm not trying to claim this was good style, or a good idea. (As I
said in my earlier article, I've since renamed as many special
variables as possible in the *FOO* style.) All I'm trying to claim is
that this example shows that the problem is not confined to beginners.
It was created by experienced programmers, and it bites experienced
programmers now who have to worry about not naming local variables
NO-LOADS. And even now that the special variables have been renamed
in the *FOO* style in my version (SBCL), I still need to worry about
respecting constraints on the order of compilation of code, with
no help from the compiler even to tell me when something goes wrong.

Incidentally, experienced C and C++ programmers can avoid many of the
problems of C and C++, such as
* using the preprocessor to define constants
* having to manually free memory resources
* having wild pointers be able to corrupt the system
But that because these problems mostly trouble beginners (or maintainers
of large programs written by others) doesn't mean that these problems
aren't shortcomings of C and C++. Why should the fact that the special
variable problem mostly troubles beginners (or maintainers of large
programs written by others) mean that this problem isn't a shortcoming
of Common Lisp?

Tim Bradshaw

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* wnewman wrote:
> Incidentally, experienced C and C++ programmers can avoid many of the
> problems of C and C++, such as
> * using the preprocessor to define constants
> * having to manually free memory resources
> * having wild pointers be able to corrupt the system


Most of the experienced C and C++ programmers I know spend most of
their time avoiding the latter two and/or buy very expensive tools
(purify) to help them. Most of them are *very* troubled by these
issues!

There's a real difference between problems which just go away, and
problems that you eventually realise you can live with, but will just
cost you 30% of your time for ever.

The CMUCL thing is a fine example of the former. Whoever did that was
being silly, and there's a once off fix involving DO-SYMBOLS and
tags-query-replace in emacs which really should not take that long.

--tim

Erik Naggum

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* wne...@my-deja.com

| All I'm trying to claim is that this example shows that the problem is
| not confined to beginners.

but your example doesn't show any such thing! that people are not
following the asterisk convention is _not_ the problem. the problem as
stated is that there's a lambda list or let binding somewhere with a
symbol in it that has special binding which comes as a _surprise_ to
people who are moderately (but not overly) intimate with the code. do
you have evidence of that, or is this only more unfounded fear that there
_might_ be a problem? incidentally, I recognize that there _might_ be a
problem, the solution to which is to make the system easier to query for
such information. I don't see any other problems that need solving.

my philosophy, in case you need to have it stated to avoid speculating
about it, is that in order to serve the needs of any community, one must
never, _ever_ to cater to the needs of ignorants and novices except in
carefully controlled settings where the express purpose is to make them
non-ignorants and non-novices, such as school or training courses.

#:Erik

Tom Breton

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
g...@jpl.nasa.gov (Erann Gat) writes:

> In article <ey3ln42...@cley.com>, Tim Bradshaw <t...@cley.com> wrote:
>
> > I think I agree with Erik about this. There is clearly a problem here
> > in principle. In practice I have *very* seldom been bitten by it, and
> > I'd be loth to change the language to make it `easier' for people at
> > the cost of adding something like the BIND macro you suggest (at
> > least, not with the syntax you suggest, which I have much the same
> > reaction to as Erik I'm afraid). I'm also very loth to use up one of
> > the extremely small number of available characters to be a read-macro
> > for something like this.
>

> I see I have not made myself clear.


>
> The $ macro is optional.

If it's optional, ISTM it doesn't solve the problem (such as the
problem is). Using *...* is also optional. So is using (declare
(special ...)) when it's not strictly needed.

>
> Personally, I think:
>
> (bind x 1 $q 2 (values y z) (foo) (a $b c) (baz) in ...
>
> is a win.

[]

> I also wonder how many of you BIND haters are also LOOP haters. I am
> really beginning to worry that people have lost sight of the fact that
> an S-expression with just one level of parens is still an S-expression.

Well, we have a real serious disagreement there. I don't think you
have the feel for sexps. Sticking parens around something may
technically make it a sexp, but it doesn't make it a tolerable one. A
sexp should not have internal dependencies. IMO even boa parameter
lists are iffy.

> > I'd also like to gratuitously point out that your technique doesn't
> > actually solve the whole problem: symbol-macros can mean that what
> > looks like an innocent variable is actually something entirely
> > different.
>

> But symbol macros can only be established with lexical scope, so if
> there is a symbol macro it must be lexically manifested. Global symbol

> macros would be truly problematic. In fact, this is the problem with
> DEFVAR. It essentially establishes a global symbol macro that replaces
> all occurrences of X with (symbol-value 'x), except that this happens

> silently, and there's no way to undo it.

Instead of all this, how about a system parameter that makes even
defvar require (declare (special ...)) or it's an error?

--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html

Erik Naggum

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* Erann Gat

| The problem is not special variables. The problem is the way you tell
| Lisp which variables you want to make special and which you don't.

so let me disagree vociferously with that, too. if we make necessary
things inconvenient to express, it is not their expression that will
suffer the most, but common recognition of their necessity. the fact
that special variables solve a problem that exist in _every_ programming
language so conveniently, namely how to ascertain proper restoration of
global variables, means that people aren't going to reinvent tricks with
unwind-protect and the like (if they know about unwind-protect -- Kent
Pitman has made the cogent argument that languages can be judged on the
existence of such a language feature -- I'll argue that the same applies
to programmers and whether they know about it).

as soon as you start to make these special variables stand out as the
wart on the language that you appear to believe they are, people will
naturally avoid them (and the more so the more weirdo syntax soup you
introduce, the threat of which I now realize is part of my objection to
your syntax-heavy proposal), and choose the next best thing that looks
like it could be sufficiently convenient. then they start to make buggy
or needlessly verbose code, which they'll loathe. you're rocking the
boat and making life miserable for those who _need_ special variables and
need them _not_ to look _too_ special, because that destroys their very
significant convenience factor. I say: don't do that. solve the actual
problems, don't just push your special brand of cosmetics.

| The issue is not just one of querying. It's also one of control. There's
| no way to undo the effects of a defvar short of uninterning the symbol.

so let's find a way to do that, instead, then. (how hard can this be?)

I think a Common Lisp environment needs universal functionality to "undo"
or "kill" all definition forms. Allegro CL has a nifty feature to kill
various definitions from the Emacs interface, and I use it seldom enough
to appreciate it very highly every time, but it does not accept defvar.
(I'll file a request for enhancement for that.) this might be considered
annoying, but in the meantime, here's a couple tiny functions to muck
with the gory internals of symbols in a way that is guaranteed to make a
whole slew people want to puke violently, but if they get over it and
realize that Common Lisp is all about _exporting_ an elegant interface to
lots of really hairy stuff to begin with, they might actually rejoice and
use these functions.

(in-package :excl)

#+allegro-v5.0.1
(defun symbol-special-p (symbol)
(declare (optimize (speed 3) (safety 0)) (symbol symbol))
(check-type symbol symbol)
(if (and (not (eq nil symbol))
(zerop (ldb (byte 1 #.(system::mdparam 'compiler::md-symbol-flag-constant-bit))
(excl::sy_flags symbol))))
(not (zerop (ldb (byte 1 #.(system::mdparam 'compiler::md-symbol-flag-globally-special-bit))
(excl::sy_flags symbol))))
nil))

#+allegro-v5.0.1
(defun (setf symbol-special-p) (special symbol)
(declare (optimize (speed 3) (safety 0)) (symbol symbol))
(check-type symbol symbol)
(if (and (not (eq nil symbol))
(zerop (ldb (byte 1 #.(system::mdparam 'compiler::md-symbol-flag-constant-bit))
(excl::sy_flags symbol))))
(setf (excl::sy_flags symbol)
(dpb (if special 1 0)
(byte 1 #.(system::mdparam 'compiler::md-symbol-flag-globally-special-bit))
(excl::sy_flags symbol)))
(error "Cannot change special status of constant symbol ~S." symbol)))

perhaps needless to say, you can hurt your Allegro CL system with the
latter function, even though I have tried to restrict a few particular
damages that users are likely to try (and I know how to restrict).

if you don't have Allegro CL 5.0.1, this won't necessarily fail, but _you_
had to remove the read-time conditionals so _you_ take the responsibility.

| > again, there is a need to change the language to make it more amenable to
| > beginners and experienced users alike: unlike all other languages now in
| > current and widespread use, Common Lisp violates the notion that what you
| > see is what you get with respect to the _names_ of the symbols.
|
| Maybe it would help to review the distinction between a variable and a
| symbol (and the name of a symbol) just to make sure we are all on
| the same page.

find, but sometimes, it isn't everybody else who need to be on your page.

| The point is that none of this has anything to do with symbol names.

duh. I'm trying to redirect your attention to a worth-while problem,
entirely _away_ from messing with stuff you shouldn't be messing with.

| I thought that's what I was doing, but it seems I still have not made
| myself clear. You seem to think that I am saying that the problem is
| the existence of dynamic variables and symbol-value. I'm not saying
| that at all. What I am saying is that the way things currently stand,
| when you write 'X' you can't in general know whether what you've written
| is a reference to a stack frame or a slot in an object on the heap.
| And, in fact, as you yourself pointed out the meaning of X can change
| over time if you are running interpreted. IMO that's bad.

and IMNSHO, it isn't bad at all. I have pointed out that we need a few
accessors into the environment to solve your uncertainty problem, and
perhaps we need a `notspecial' or `lexical' declaration to be able to
undo the pervasive effects of the `special' declaration. however, I care
so much about the language that I'm unwilling to consider your proposal
when I understand the issues so much better than you do and I consider
your proposal to be a major disturbance over a petty issue that mainly
has to do with a disportional sense of uncertainty. now, I fully
recognize that uncertainty is one of those things that make people go
nuts and that it is vitally important in a community to avoid swarms of
neurotics who run around with proposals that are mainly intended to
affect their mental state in some vaguely positive way, so I instead
propose something that will make the uncertainty go away by adding a very
low-level certainty instead of making any changes to superficial features
that will take yet more forms as the swarm of neurotics has only been
decimated for now, not actually cured of their unhealthy uncertainty.

| > it's not a question of case,
| > it's a matter of making (setf (readtable-case *readtable*) :preserve)
| > work the way people _actually_ expect it to. think about it. please.
|
| It would help if you would stop talking in riddles.

geez. there are no riddles. I'm talking about something other than you
do, because I think what you're talking about is counter-productive. you
missed that point entirely when you thought I was still talking about
your concerns over specialness when I talked about symbol names. I'm a
little concerned with the breakdown of communication that occurs when
people don't notice that others aren't talking about the same thing they
are, anymore, but just keep on and on about whatever they had in mind.

| Works the way I'd expect it to.

so try typing in (setf (readtable-case *readtable*) :upcase) and tell me
what you expect to happen and/or that this is not a useful thing to do.
(note again that this is no longer a question of special variables.)

#:Erik

Pierre R. Mai

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
Robert Posey <mu...@raytheon.com> writes:

[ Reviewing code ]

> Usually, its sent as a text file and I review it as a separate file on
> a PC, in a code highlighting editor. So there is no way for the system
> to know data from other files. This is partly a result of using Ada, and

I wouldn't blame Ada itself for this. There are Ada environments out
there, that integrate fairly well with "modern" tools. But I know
what you mean: There are also some fairly clunky Ada tool-chains out
there.

> old very limited tools. Since we are switching to C/C++, hopefully we will
> start using smart tools. So I have zero experience reviewing other people's

I wouldn't hang my hopes too high, though. I think the usability of a
development environment corellates highly with the organization in
question, and less with the actual languages used, or the environments
available.

> code, using reasonable tools. My LISP coding experience is so far
> simply class work or playing around, and is pretty limited at the
> moment. Another problem is that many programs have classified code
> on them, which means that some small part of the code is classified.
> What I work on is not classified, so I often have limited access.

Yes, in classified environments, usability often suffers hideously.
Been there, done that, got the scars and no T-shirt. :)

> to see massive resistance to using an advanced features. However, I
> still think that you are going to run into problems if you don't use
> structured names, it seems so much easier to read the code that way.

Oh, I didn't advocate not using structured names. I mean all the
tool support in the world isn't going to help you when you've got
a mess of uncommunicative variable names floating around.

I just don't think that using filenames for structure is the right
approach. The name of the file something is defined in only matters
when you want to open that file. With a modern environment, you just
press M-. or M-, and the editor will pop up the definition of the
thing at point. Together with the fact that files are just one way of
organizing source code (many advanced environments are moving to
non-file based repositories -- which has it's advantages and
disadvantages), that makes files not very meaningful.

What I do advocate is naming files in a way that makes the logical
"location" of something apparent, so that you can see what something
means (and in a hitch, given useful filenaming conventions, you could
even find in manually).

For example naming functions like the following (this isn't a mechanical
matter, since you have to take non-related class hierarchies into account):

;;; Class with reader

(defclass http-message ()
((server :initarg :server :reader http-message-server
:documentation "The server this message belongs to.")))

;;; Accessor

(defgeneric http-message-version (message)
(:documentation "Returns the HTTP-Version of the given message."))

;;; "Action"

(defgeneric render-http-message (message stream)
(:documentation "Render the given message on the stream."))

Accessors for attributes of objects get names like

logical-name-attribute

and actions on objects get names like

verb-logical-name(-prepositional-phrases)

Note that the logical-name in question is often but not always the
name of the top class for which this operation makes sense (i.e. which
"introduces" this operation). In cases where unrelated class
hierarchies define methods on the GF in question, a logical
name for the generalization must be found (see for example the object
in print-object, where ANSI CL has no class named object).

While it is more difficult to get people to use logical instead of
mechanical naming conventions consistently, I think it's worth the
effort. With critical reviews of chosen names during code reviews,
and the discussions they'll cause, you will get a) fairly consistent
naming, and much more importantly b) a steadily re-established general
consensus on the important concepts of your project, their names,
meanings and implications.

> Its a pain to always have to click on every symbol to find out what
> it really means.

This shouldn't ever be necessary. If you get to this stage, you're
generally lost.

wne...@my-deja.com

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
In article <ey3u2iq...@cley.com>,

Tim Bradshaw <t...@cley.com> wrote:
> * wnewman wrote:
> > Incidentally, experienced C and C++ programmers can avoid many of
the
> > problems of C and C++, such as
> > * using the preprocessor to define constants
> > * having to manually free memory resources
> > * having wild pointers be able to corrupt the system
>
> Most of the experienced C and C++ programmers I know spend most of
> their time avoiding the latter two and/or buy very expensive tools
> (purify) to help them. Most of them are *very* troubled by these
> issues!
>
> There's a real difference between problems which just go away, and
> problems that you eventually realise you can live with, but will just
> cost you 30% of your time for ever.

Yes, I am not trying to argue that the special variable thing is a big
problem; certainly not one on the scale of the big C problems. But I
thought Erik was off base to say that because experienced programmers
know how to avoid it it's a non-problem. I think it's like the
preprocessor problems, or the confusion of C declarator syntax, a
price which is worth paying for a useful and stable language, but
IMHO unquestionably a flaw in the language.

Incidentally, while looking back through my development log for
the string "special variable" to find the symbol names, I noticed
that I'd actually logged a case where this had caused problems
for me. Fortunately they were gross problems (raising an error
because of an unbound variable) instead of subtle problems of
silently computing the wrong answer.

PROBLEM:
Assembling assembly/x86/assem-rtns.lisp fails with
RETURN-MULTIPLE assembled
TAIL-CALL-VARIABLE assembled
THROW assembled
UNWIND assembled
Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:
the variable %C::*FIXUPS* is unbound.
MUSING:
Searching for all references to *FIXUPS* shows
that it is bound in ASSEMBLE-FILE and GENERATE-CODE.
BACKTRACE from the error shows
0: ("DEFUN NOTE-FIXUP" #<unused-arg> 187)
1: (%ASSEM::FILL-IN #<Closure Over Function "DEFUN NOTE-FIXUP"
{480FA399}> 0)
2: (%ASSEM::PROCESS-BACK-PATCHES #<%ASSEM:SEGMENT :NAME "Regular">)
3: (%ASSEM:FINALIZE-SEGMENT #<%ASSEM:SEGMENT :NAME "Regular">)
4: (%C:ASSEMBLE-FILE "src/assembly/target/assem-rtns.lisp"
:OUTPUT-FILE
"obj/from-xc/assembly/target/assem-rtns.lisp-obj-tmp"
:TRACE-FILE
...)
5: (COMPILE-STEM "assembly/target/assem-rtns" :OBJ-PREFIX
"obj/from-xc/" :OBJ-SUFFIX ...)
6: (IN-TARGET-CROSS-COMPILATION-MODE
#<Closure Over Function "LAMBDA (STEM &KEY ASSEM-P
IGNORE-FAILURE-P)" {48005A41}>)
7: ("Top-Level Form")[:TOP-LEVEL]
So why the heck isn't *FIXUPS* bound, then?
I tried to look at the problem more closely using
/SHOW statements, and it went away. I guess it went
away simply because I recompiled and/or reloaded
assemfile (with HOST-CLOAD-STEM). I tested whether
rebuilding assemfile with TARGET-COMPILE-STEM would
cause the problem to return, and it didn't. This
is weird..
Oh! *FIXUPS* is only declared special by
DEFVAR *FIXUPS* in compiler/fixup.lisp, and in my
stems-and-flags.lisp-expr build sequence,
assembly/assemfile is compiled before compiler/fixup.
CMUCL doesn't notice this problem because *FIXUPS*
is used in a function call which is lexically inside
ASSEMBLE-FILE: its only mechanism for raising a
warning related to this is when the undeclared
special variable isn't used within the lexical body
at all. So the compilation silently had different
semantics when done in the ordinary build process
and when done later interactively, after *FIXUPS*
had been declared special. And no warnings or
errors were raised along the way. (Common Lisp's
special variable system really is somewhat dain-bramaged..)
FIX:
* Declare %C::*FIXUPS* special in early-c.lisp, 'way early
in the build sequence.

Perhaps the bewildered tone of my notes to myself at the time
show that I was not (and perhaps never will be:-) an Erik-level
real programmer, but I am at least a programmer in the real world,
and I was actually bitten by this problem.

> The CMUCL thing is a fine example of the former. Whoever did that was
> being silly, and there's a once off fix involving DO-SYMBOLS and
> tags-query-replace in emacs which really should not take that long.

Yes, it was silly. And yes, I fixed it exactly this way, although it
turned out to be sufficiently tedious that for one particularly
prolific family of misnamed specials I just gave up. From my log again:

* The FOO-TN-named variables created by
the DEF-MISC-REG-TNS macro are too numerous and used
too widely for it to be reasonable to rename them
to *FOO-TN*. For now I'll leave them alone, with a
FIXME note wishing they were constants.

Erann Gat

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
In article <31609668...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> * Erann Gat

> | The issue is not just one of querying. It's also one of control. There's
> | no way to undo the effects of a defvar short of uninterning the symbol.
>
> so let's find a way to do that, instead, then. (how hard can this be?)

Pretty hard, apparently. My first choice would have been to add
(declare (lexical ...)) But that was tried and rejected be people
who understand the problem much better than I do.

> | Maybe it would help to review the distinction between a variable and a
> | symbol (and the name of a symbol) just to make sure we are all on
> | the same page.
>
> find, but sometimes, it isn't everybody else who need to be on your page.

N.B. The Common Lisp Standard uses the word "name" in two differenct
senses. It can mean a string assocated with a symbol (the symbol-name)
or it can mean a symbol (or some other object) associated with a
variable or binding (the Standard makes variable a synonym for binding).
When I wrote my response I thought Erik was using the word "name" in
the first sense. Last night I discovered the second meaning and
decided that he must have meant it in the second sense. Now it
appears that I was right all along and he was just changing the subject.

> | The point is that none of this has anything to do with symbol names.
>
> duh. I'm trying to redirect your attention to a worth-while problem,
> entirely _away_ from messing with stuff you shouldn't be messing with.

Thank God we have Erik to guide us to worthwhile problems!

> and IMNSHO, it isn't bad at all. I have pointed out that we need a few
> accessors into the environment to solve your uncertainty problem, and
> perhaps we need a `notspecial' or `lexical' declaration to be able to
> undo the pervasive effects of the `special' declaration

Like I said, this was proposed and rejected. Why beat a dead horse?

> however, I care
> so much about the language that I'm unwilling to consider your proposal
> when I understand the issues so much better than you do and I consider
> your proposal to be a major disturbance over a petty issue that mainly
> has to do with a disportional sense of uncertainty.

And I care so much about the language that I'm unwilling to drop the
matter just because some arrogant self-appointed guru says I should.

BTW, why would adding a LEXICAL declaration be any less disruptive
than allowing variable names of the form (special X)? The vendors
would still have to change their implementations to support it.
Unlike other declarations, you can't ignore SPECIAL/LEXICAL declarations
and still preserve correct semantics. This fact alone indicates that
declarations are the wrong place for this information.

> | Works the way I'd expect it to.
>
> so try typing in (setf (readtable-case *readtable*) :upcase) and tell me
> what you expect to happen and/or that this is not a useful thing to do.
> (note again that this is no longer a question of special variables.)

I would expect to have to hold down the shift-lock key before I could
set the readtable case back to upcase. Honestly, I don't see the problem
here.

E.

Tim Bradshaw

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* Erann Gat wrote:

> Pretty hard, apparently. My first choice would have been to add
> (declare (lexical ...)) But that was tried and rejected be people
> who understand the problem much better than I do.

But people working under constraints like getting the standard out the
door in reasonable time. Just because it was rejected does not mean
it is not a reasonable thing to do. Syntactic environment access was
also rejected. A MOP is not in there. Unless you know why it was
rejected you don't know whether it's a good idea.

--tim

Tim Bradshaw

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
This whole thread reminds me of an article I once read on why the UK
government should not pass legislation banning fox hunting.

(If you're not in the UK you may not be aware of this issue: we have a
tradition of hunting foxes with dogs which is a fairly barbaric
process and also very much a class issue. There is wide support for
banning it except among the country-based upper/upper-middle classes.)

The article started off by stating clearly that the author considered
fox hunting barbaric. However it claimed that legislation should
*not* be worked on because there are an awful lot of other things
which are barbaric and should be stopped, and a lot of those do a lot
more damage to animals and people than fox hunting. Since getting
legislation through takes time, and since getting anti fox hunting
legislation through was likely to be contentious and slow, the article
claimed that the best use of the finite time resources available was
to pass other legislation which had more benefit.

This is just like that. Obviously having some better approach to
specials would solve some number of problems. But there other things
that could be done, and there are finite resources to do them. So
things need to be prioritised, based on what does the most good.

One way of working out the priorities
is to look at what vendors are doing. If lots of people are
complaining at them about this issue, then they will start releasing
implementations with various solutions to the problem. Vendors are
very simple creatures, driven largely by customer demand, so they
provide this nice experimental mechanism for discovering what the real
problems are.

Unfortunately vendors can suffer from the usual local-minimum problem
that you get with gradient descent. But you can fix that. If you
think this is a real problem, produce an implementation that fixes it
(start with one of the existing free CLs, make it do what you want).
If the issue is a real problem then people will soon be clamouring at
the vendors, and before you know it there will be n different
solutions to the problem.

At *that* point, it is appropriate to start thinking about making
changes to the standard language.

Complain at your vendor or produce an implementation which solves the
problem. But whatever you do, don't just sit there whining on c.l.l.
Far too many people do that.

--tim

(please do not assume this article tells you anything about my
position on fox hunting.)


Erik Naggum

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* Erann Gat

| Pretty hard, apparently. My first choice would have been to add (declare
| (lexical ...)) But that was tried and rejected be people who understand
| the problem much better than I do.

proposals are rejected or adopted in context. if a good idea is served
alone or in a context that is not conducive to furthering principles that
are valued higher by others than some small improvement, it will, as it
should, be rejected. how can _anyone_ have a problem understanding this?
have you never proposed something, had it rejected, then seen it picked
up by others only to be adopted? this is clearly not because people hate
you, but because you didn't do your homework, and somebody else did.

| Thank God we have Erik to guide us to worthwhile problems!

huh? were you _consciously_ trying to guide us to a _worthless_ problem,
or is it wrong for _me_ to guide to worthwhile problems, while _you_ can
pick worthwhile problems at will? no wonder your proposals don't get
accepted if this is how you deal with contributions. sheesh!

| > and IMNSHO, it isn't bad at all. I have pointed out that we need a few
| > accessors into the environment to solve your uncertainty problem, and
| > perhaps we need a `notspecial' or `lexical' declaration to be able to

| > undo the pervasive effects of the `special' declaration
|
| Like I said, this was proposed and rejected. Why beat a dead horse?

I feel like I'm spoonfeeding a child. it's because it's a question of
getting agreement among people who have already made up their mind about
a number of issues you may not know about, and this means you must not
piss people off with pure _drivel_. as I have strongly indicated, your
inclusion of silly new syntax is a _good_ reason to reject all of your
proposal. like the old saying goes, with all this shit, there must be a
pony somewhere, take away the crud, and what's left may not be a dead
horse. but feel free to blame somebody for your failure to get agreement.

| And I care so much about the language that I'm unwilling to drop the
| matter just because some arrogant self-appointed guru says I should.

oh, geez, get _over_ yourself. what's this, the emperor's new argument?
who do you think you're fooling?

isn't it just _too_ odd how often some doofus "self-appoints" someone
_else_ to some status to which they themselves would never actually
_self_-appoint themselves? what's the point with such dishonesty and
such incredible silly behavior as to pretend that others _self_-appoint
themselves when in fact there's a lunatic at large who does both the
appointing and the accusation of such appointing all by himself?
whatever is _wrong_ with you? you've come up with a bunch of really bad
thinking and it must be shot down fast before you revamp the whole
language, but still, there are a few good things in there and there's
some work that can be turned into productive ideas and proposals, but
what do you do? you're only being silly and negative and concentrate on
dead horses and rejection. and now you're out picking a silly fight?
what's the _point_ with this? pull yourself _together_, damnit!

| BTW, why would adding a LEXICAL declaration be any less disruptive than
| allowing variable names of the form (special X)? The vendors would still
| have to change their implementations to support it. Unlike other
| declarations, you can't ignore SPECIAL/LEXICAL declarations and still
| preserve correct semantics. This fact alone indicates that declarations
| are the wrong place for this information.

well, I don't generally and didn't now make just one big proposal and
feel personally defeated when it was rejected as a silly idea. believe
it or not, but I have tried to figure out what would completely supersede
your silly idea such that even you would be happier with the solution.
this, however, is doomed to fail miserably as long as you only take the
negative views on everything, completely ignore the good stuff (notice
that I don't) I say, and huff and puff a lot instead of trying to solve
the _problem_ you have, the _adopted_ solution to which is very unlikely
to be whatever you dreamt up to begin with, anyway. you're not being
constructive about this at all. that annoys me to no end, because you
raise issues that need to be resolved, and the way you go about it, it's
unlikely that we will very find the consensus to resolve them. again,
pull yourself together, damnit!

| > | Works the way I'd expect it to.
| >
| > so try typing in (setf (readtable-case *readtable*) :upcase) and tell me
| > what you expect to happen and/or that this is not a useful thing to do.
| > (note again that this is no longer a question of special variables.)
|

| I would expect to have to hold down the shift-lock key before I could
| set the readtable case back to upcase. Honestly, I don't see the problem
| here.

OK, could you explain why it is unreasonable to think that holding down
the shift key while typing that line in is a _misfeature_? can you
explain why it is unreasonable to give a conforming Common Lisp system
the ability to deal with :preserve _and_ lower-case, like beginners and
experts alike see in all the textbooks and examples on the Net and which
they have come to expect from _other_ languages they use?

I'm doing this also as an experiment to see if you can at all relate to
what other people tell you about their problems, since I have evidence
that you have a very hard time dealing with stuff you don't dream up on
your own, and if you can at least show that you can wrap your head around
another problematic issue, there might be grounds for figuring out what
would _really_ solve your other problems, without _having_ to accept your
proposals verbatim. as I said, you have raised certain relevant issues
that I think are quite important, but only to be met with childish
bickering and an _incredibly_ stupid "self-appointed guru", instead of a
desire to help resolve the parts of your concerns that others respond
_well_ to. I could do without the rampant stupidity, so what _is_ your
problem? exercise some mental _focus_, dude!

sheesh!

#:Erik

Erann Gat

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
In article <m3snyaf...@world.std.com>, Tom Breton <t...@world.std.com> wrote:


> > Personally, I think:
> >
> > (bind x 1 $q 2 (values y z) (foo) (a $b c) (baz) in ...
> >
> > is a win.
> []
>
> > I also wonder how many of you BIND haters are also LOOP haters. I am
> > really beginning to worry that people have lost sight of the fact that
> > an S-expression with just one level of parens is still an S-expression.
>
> Well, we have a real serious disagreement there. I don't think you
> have the feel for sexps. Sticking parens around something may
> technically make it a sexp, but it doesn't make it a tolerable one. A
> sexp should not have internal dependencies. IMO even boa parameter
> lists are iffy.

I'm not sure what you mean by internal dependencies, but there is no
difference in spirit between my BIND and the standard LOOP.

(bind x = 1 and y = 2 in ...)

is exactly the same as

(loop for x = 1 and y = 2 return ...)

except for the particular choice of keywords. (The only difference is
that in my BIND macro some of the keywords are optional whereas in LOOP
they are all required.)

E.

Russell Wallace

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
Erik Naggum wrote:
> ...that people aren't going to reinvent tricks with

> unwind-protect and the like (if they know about unwind-protect -- Kent
> Pitman has made the cogent argument that languages can be judged on the
> existence of such a language feature -- I'll argue that the same applies
> to programmers and whether they know about it).

Can you give a reference to this, or summarize the argument in
question? I must admit it wouldn't have occurred to me to pick that as
one of my primary criteria for judging languages (let alone
programmers), I'm curious as to the reasoning?

--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:mano...@iol.ie

Christopher C Stacy

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
At MIT back in the days of PDP-10 MACLISP, before Scheme, there was a
competing programming language called MDL. It's most popular claim to
fame is that it was the language that ZORK was written in.

MDL had infix syntax operators that made a symbol evaluate globally
or locally. I have forgotten the exact way it worked, but it was
something like: ,A is the special A and .A was the lexical A.
And I am sure there was a default for just A but I forget which.

The original designers of Scheme, and the developers of MACLISP and
of ZetaLisp (the predecessor of Common Lisp) were familiar with MDL.


Tim Bradshaw

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* Rajappa Iyer wrote:

> Really?

Yes, really! I might like barbaric sports!


Tim Bradshaw

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* Rajappa Iyer wrote:

> Ah, my mistake. I thought that `barbaric' was normally used as a
> pejorative.

It is, I was just trying to escape from the pit I'd dug myself...

--tim

Pierre R. Mai

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
g...@jpl.nasa.gov (Erann Gat) writes:

> I'm not sure what you mean by internal dependencies, but there is no
> difference in spirit between my BIND and the standard LOOP.
>
> (bind x = 1 and y = 2 in ...)
>
> is exactly the same as
>
> (loop for x = 1 and y = 2 return ...)
>
> except for the particular choice of keywords. (The only difference is
> that in my BIND macro some of the keywords are optional whereas in LOOP
> they are all required.)

I think a number of people are not very happy with LOOP syntax, as
opposed to LOOP functionality. Given that LOOP had a considerable
history and usage before being adopted into the standard, that it
filled a non-trivial gap in Common Lisp functionality, and that it's
now "too late" anyway, we might as well make the best of it, and use
it where appropriate. That doesn't mean we have to be happy about
introducing new constructs with the same defects:

- LOOP still breaks a lot of source (i.e. text) munging code, like
indenting editors,
- LOOP keywords are not symbols (i.e. the dispatching is done on
symbol-names, not symbols, which is very bad, especially in light of
user-extensibility),
- Nesting of LOOP clauses can't be seen from automatic indentation,
- A number of constructs of CL had to be reinvented for LOOP (see
conditional clauses, destructuring), because LOOP doesn't mesh well
with the rest of CL.
- LOOP syntax is a mini Dylan/Pascal inside of CL. Thus you have to
switch between syntax styles while reading code.

Note that the above defects are defects only in the context of CL,
where they stand out as warts, because they run counter to the rest of
the CL environment.

Pierre R. Mai

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
Russell Wallace <mano...@iol.ie> writes:

> Erik Naggum wrote:
> > ...that people aren't going to reinvent tricks with


> > unwind-protect and the like (if they know about unwind-protect -- Kent
> > Pitman has made the cogent argument that languages can be judged on the
> > existence of such a language feature -- I'll argue that the same applies
> > to programmers and whether they know about it).
>

> Can you give a reference to this, or summarize the argument in
> question? I must admit it wouldn't have occurred to me to pick that as
> one of my primary criteria for judging languages (let alone
> programmers), I'm curious as to the reasoning?

See nearly any posting by Kent M. Pitman on comp.lang.lisp which
includes unwind-protect. Here are a number of Message-IDs in the last
couple of years:

<sfwlnpe...@world.std.com>
<sfwzpc8...@world.std.com>
<sfw7lz7...@world.std.com> <--- This is probably quite relevant.
<sfwlnnl...@world.std.com> <--- This too.
<sfwvhmp...@world.std.com>
<sfw7lz4...@world.std.com>

I think anyone seriously thinking about language use or design should
read all of the above...

Tim Bradshaw

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
* Pierre R Mai wrote:
> [...] Given that LOOP had a considerable
> history and usage before being adopted into the standard, [...]

This is a very significant reason for loop being a reasonable thing to
have -- large-scale experience with a closely-related system (probably
several).

--tim

Natarajan Krishnaswami

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
On Thu, 02 Mar 2000 20:15:32 +0000, Russell Wallace <mano...@iol.ie> wrote:
> Can you give a reference to this, or summarize the argument in
> question? I must admit it wouldn't have occurred to me to pick that as
> one of my primary criteria for judging languages (let alone
> programmers), I'm curious as to the reasoning?

I don't know Kent Pitman's argument, but IMO it says a great deal about
the commitment of the language designers (and indeed, the language
community) to the possibility of writing robust code. Cleaning up after
exceptional conditions is one of the central concepts in constructing
reliable software, and it speaks volumes about languages where that's
not syntactically trivial to perform.


<N/>
--
you have been evaluated. you have a negative reference count. prepare
to be garbage collected. persistence is futile.
-- Erik Naggum

Erann Gat

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
In article <31610154...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> | > | Works the way I'd expect it to.
> | >
> | > so try typing in (setf (readtable-case *readtable*) :upcase) and tell me
> | > what you expect to happen and/or that this is not a useful thing to do.
> | > (note again that this is no longer a question of special variables.)
> |
> | I would expect to have to hold down the shift-lock key before I could
> | set the readtable case back to upcase. Honestly, I don't see the problem
> | here.
>
> OK, could you explain why it is unreasonable to think that holding down
> the shift key while typing that line in is a _misfeature_? can you
> explain why it is unreasonable to give a conforming Common Lisp system
> the ability to deal with :preserve _and_ lower-case, like beginners and
> experts alike see in all the textbooks and examples on the Net and which
> they have come to expect from _other_ languages they use?

OK, I'll bite.

People are used to languages that are case-sensitive, where the default
readtable-case (indeed the only readtable-case available to them) is
:preserve, and where most keywords are lower case, or a mix of primarily
lower case with some upper case.

Common Lisp is case-sensitive like people expect. But the default
readtable case is :upcase rather then :preserve, and the keywords
(i.e. the names of the standard symbols) are all upper case.

I don't know whether this last item is part of the standard or simply a
consequence of the default read table case being :upcase.

In any case, to make CL act like every other language out there we'd
have to 1) change the default readtable-case to :preserve and 2) change
the names of all the standard symbols. If (setf (symbol-name ...) ...)
were legal this would be easy, but it isn't, so it's not. Straightforward
implementation-specific hacks won't work because the symbol name is
stored in many places, not just in the symbol. In MCL:

? (setf y 'x)
X
? (setf (uvref 'x 0) "x")
"x"
? y
#|symbol not found in home package!!|#COMMON-LISP-USER::\x
?

You could make duplicate symbols with lower-case names and copy their
value, function, and plist slots, but this would probably break
most compilers, which probably have code like (case (car form) (if ...

You could change INTERN to use STRING-EQUAL instead of STRING= when
determining whether a symbol already exists or not.

Or you could just tell beginners not to mess with readtable-case at all
since the :upcase default generally does the Right Thing.

E.

Frank A. Adrian

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
Erik Naggum <er...@naggum.no> wrote in message
news:31609668...@naggum.no...

> | The issue is not just one of querying. It's also one of control.
There's
> | no way to undo the effects of a defvar short of uninterning the symbol.
>
> so let's find a way to do that, instead, then. (how hard can this be?)

Well, the problem is that it's a nonsensical idea in the first place.
Unless I'm mistaken (and I'm sure Eric will tell me if I am :-), as defvar
is the same as creating a global symbol, proclaiming it special, and
(possibly) setting its symbol-value slot to a value, undoing it would be
unbinding the value, proclaimimg the variable no longer special, and
destroying the global symbol. Since the value would be unbound from the
symbol by its destruction anyway (and the proclaimation would be senseless),
you might as well not do it. In, other words, the inverse operation for
defvar IS unintern.

If Erran doesn't like the term unintern, here's a nice macro for him:

(defmacro undefvar (var) `(unintern ',var)) ;pardon my indentation...

faa


Frank A. Adrian

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to
Erann Gat <g...@jpl.nasa.gov> wrote in message
news:gat-020300...@milo.jpl.nasa.gov...

> People are used to languages that are case-sensitive, where the default
> readtable-case (indeed the only readtable-case available to them) is
> :preserve, and where most keywords are lower case, or a mix of primarily
> lower case with some upper case.

People are also used to languages that need explicit type declarations
everywhere, all the time, too. This does not mean that it would be a GOOD
thing to add this to Lisp. What you seem to be espousing is that no one who
has ever learned any language should ever be surprised by the features of
another. The only way to achieve this would be to have only a single
language. As long as this is Lisp, I have no problem with this :-).
Otherwise, I believe that your goal is misguided.

> Common Lisp is case-sensitive like people expect. But the default
> readtable case is :upcase rather then :preserve, and the keywords
> (i.e. the names of the standard symbols) are all upper case.

And there is good historical precedence for doing so. One of the Common
Lisp standard committee's jobs was to unify the common threads of that
time's current diverging implementations. This meant attempting not to
break existing code if possible. Almost all of the then current Lisp
implementations had this feature.

> I don't know whether this last item is part of the standard or simply a
> consequence of the default read table case being :upcase.

See above. It was done to not gratuitously break as much code as possible.

>
> In any case, to make CL act like every other language out there...

And this is good how?

> ...we'd


> have to 1) change the default readtable-case to :preserve

And have to sort through tons of compiler warnings or run time errors in
existing code. And for what?

> ... and 2) change


> the names of all the standard symbols.

Which really would be insane.

> If (setf (symbol-name ...) ...)
> were legal this would be easy,

Why SHOULD it be legal? setf'ing a symbol-name slot could lead to more
trouble than anything ever suggested.

> but it isn't, so it's not.

And thank God (or the ANSI comittee) for that.

> Straightforward
> implementation-specific hacks won't work because the symbol name is
> stored in many places, not just in the symbol.

Actually, the symbol-name may only be stored in one place, it may be stored
in many places, and it may not be stored anywhere. The only thing the spec
says is how that symbol is supposed to behave functionally, not
implementationally. As far as we know, some implementation, somewhere, may
store its symbol-name slot up your ass.

You know, I'm beginning to think that Erik is right and you really are a
brick.

faa

Coby Beck

unread,
Mar 2, 2000, 3:00:00 AM3/2/00
to

Frank A. Adrian <fad...@uswest.net> wrote in message
news:3FIv4.5484$a82....@news.uswest.net...

> Erann Gat <g...@jpl.nasa.gov> wrote in message
> news:gat-020300...@milo.jpl.nasa.gov...
>
> You know, I'm beginning to think that Erik is right and you really are a
> brick.
>
> faa
>

What an assinine comment.

People who throw insults like this around so casually should get back in
touch with the rest of humanity and understand that it does NOTHING but
weaken whatever argument they are really trying to make. Ad Hominum is the
last gasp of the desperate loser, so if you really do have an intelligent
contribution (as many with this contemptible style seem to) why degrade it
with such childish potshots?

Coby

Tom Breton

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
g...@jpl.nasa.gov (Erann Gat) writes:

> In article <m3snyaf...@world.std.com>, Tom Breton <t...@world.std.com> wrote:
>
>
> > Well, we have a real serious disagreement there. I don't think you
> > have the feel for sexps. Sticking parens around something may
> > technically make it a sexp, but it doesn't make it a tolerable one. A
> > sexp should not have internal dependencies. IMO even boa parameter
> > lists are iffy.
>

> I'm not sure what you mean by internal dependencies, but there is no
> difference in spirit between my BIND and the standard LOOP.

Sorry, that is not a plus.

Erik Naggum

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
* Russell Wallace <mano...@iol.ie>

| Can you give a reference to this, or summarize the argument in question?

Pierre R. Mai relieved me (thanks!) of searching for the articles where
Kent has made this point, but my understanding of this issue is that any
language that has the ability to do non-local transfers of control needs
a mechanism to ensure that invariants and pre- and post-conditions are
maintained even across them. that is, _if_ you care about maintaining
invariants and pre- and post-conditions (which could collectively be
thought of the very sanity of your code), and that's where I extend this
argument to apply to programmers. most modern languages now have several
sometimes _very_ powerful means of non-local transfers of control, such
as exception handling. outside of Common Lisp, none of them make sanity
maintenance convenient, what with all the declarations and "try" blocks
and everything. a programmer who doesn't care about the sanity of his
code and doesn't even pause to consider the consequences of modifying the
state of a global variable (and they do exist, regardless of what people
think or do to avoid them -- consider data on disk the ultimate in global
variables) should just not be programming anything that has side effects.
and the more we think about this, the more we want heavy-duty transaction
processing and committing blocks of changes at a time, with roll-back and
journaling and all that nifty stuff that the database people have figured
out and automatized for their programmers. unwind-protect is a similar
concern for the sanity of code and data. and binding special variables
without needing unwind-protect to set and restore the values of otherwise
mere global variables is on par with automatized transaction processing
in terms of programmer convenience. now somebody wants to take that
convenience away from us with more verbose syntax and added hairiness to
the language. consider what database programmers would think about a
proposal to have to be _explicit_ about every transaction processing step
_all_ the time. that's how good programmers should react to any measure
to abridge the usefulness and convenience of special variables.

#:Erik

Erik Naggum

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
* "Frank A. Adrian" <fad...@uswest.net>

| In, other words, the inverse operation for defvar IS unintern.

unintern nukes the property list, the home package, and the functional
value of the symbol, as well as the identity of the symbol should there
be any hold-over pointers to it after re-interning. defvar affects none
of these. defvar also does not intern the symbol to begin with. ergo,
unintern is in no way the inverse of defvar. case dismissesd.

makunbound causes a subsequent defvar to initialize the value of the
variable, so clearly there is an inverse relationship right there. since
there is no need or desire to nuke the _symbol_ (especially not with all
its other properties), we only need an inverse operation for the special
property of the symbol. I have provided that as code for Allegro CL, as
a stepping stone to a supported language mechanism.

#:Erik

Tim Bradshaw

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
* Frank A Adrian wrote:
> Well, the problem is that it's a nonsensical idea in the first place.
> Unless I'm mistaken (and I'm sure Eric will tell me if I am :-), as defvar
> is the same as creating a global symbol, proclaiming it special, and
> (possibly) setting its symbol-value slot to a value, undoing it would be
> unbinding the value, proclaimimg the variable no longer special, and
> destroying the global symbol. Since the value would be unbound from the
> symbol by its destruction anyway (and the proclaimation would be senseless),
> you might as well not do it. In, other words, the inverse operation for
> defvar IS unintern.

No, it's not. DEFVAR doesn't intern or do anything like that (the
reader does that). Uninterning the symbol is much too strong an
antidote.

--tim


Pierre R. Mai

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
Tim Bradshaw <t...@cley.com> writes:

Indeed.

Pierre R. Mai

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
pm...@acm.org (Pierre R. Mai) writes:

> See nearly any posting by Kent M. Pitman on comp.lang.lisp which
> includes unwind-protect. Here are a number of Message-IDs in the last
> couple of years:
>
> <sfwlnpe...@world.std.com>
> <sfwzpc8...@world.std.com>
> <sfw7lz7...@world.std.com> <--- This is probably quite relevant.
> <sfwlnnl...@world.std.com> <--- This too.
> <sfwvhmp...@world.std.com>
> <sfw7lz4...@world.std.com>
>
> I think anyone seriously thinking about language use or design should
> read all of the above...

For users of Deja, the following URL should give you all of the above
articles (and some more). Read from early dates to late dates...

http://www.deja.com/[ST_rn=ps]/qs.xp?ST=PS&svcclass=dnyr&QRY=unwind-protect&defaultOp=AND&DBS=1&OP=dnquery.xp&LNG=ALL&subjects=&groups=comp.lang.lisp&authors=Pitman&fromdate=Jan+1+1998&todate=Jan+1+1999&showsort=date&maxhits=100

Erann Gat

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
In article <3FIv4.5484$a82....@news.uswest.net>, "Frank A. Adrian"
<fad...@uswest.net> wrote:

> You know, I'm beginning to think that Erik is right and you really are a
> brick.

And I'm beginning to think that Erik is right, and stupid assholes like
you ought to be dealt with harshly and severely. But I find I just don't
have the master's talent for vitriol (nor the stomach for it).

You quoted almost everything I wrote execpt:

> Or you could just tell beginners not to mess with readtable-case at all
> since the :upcase default generally does the Right Thing.

This might have been a clue to you that I don't really think that
there's a problem with how CL handles case.

Now I'll follow Erik's example again and invite you to think (if you
are capable of it) about why I might have written what I did despite
the fact that I don't see a proble with how CL handles case.

E.

Erik Naggum

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
* Erann Gat

| Common Lisp is case-sensitive like people expect.

we might as well conclude at this time that special variables work just
the way people expect, because we make a semi-conscious decision to
ignore those values of "people" where "expect" returns false. _some_
people, however, do not expect the same as you do, and they might even
react the same way you do to some aspect of special variables ("it's
EVIL!") to some aspects of upper-case symbol names. it's _so_ amusing
that you don't get this.

the point being, put like a nice little riddle: those who have problems
with symbol-value are also likely have problems with symbol-name.

| I don't know whether this last item is part of the standard or simply a
| consequence of the default read table case being :upcase.

the symbols are all upper-case and Lisp has case conversion because the
languages that Lisp talked to had upper-case names and case conversion,
FORTRAN in particular. since symbols are first-class citizens in Lisp,
and not in most other languages, we have been stuck with them in a way
that other languages haven't. other languages have moved on to a much
richer character set (the upper-case thing was merely an artifact of the
terminal equipment and punched cards on which the code was written) and
have dispensed with case conversion because it loses information that is
now more readily available.

| In any case, to make CL act like every other language out there we'd have
| to 1) change the default readtable-case to :preserve and 2) change the


| names of all the standard symbols.

that's the straightforward answer, but now you're going into this
"there's only one solution to this problem, and that's the one I just
dreamt up, but since I didn't like the problem, I dreamt up a bad
solution, so therefore the problem is also bad" mode which seems to have
an incredible attraction to you. I'm explicitly trying to get you _off_
of that path. can you work with me on this, please?

Allegro CL has the ability to do just what you're describing, and has had
it forever because of the Franz Lisp legacy -- it was lower-case and case
sensitive. today, excl:set-case-mode actually converts symbol names from
upper-case to lower-case. Allegro CL is actually built with lower-case
symbol names, upper-cased as a step in building the distributed version
to customers. this is not a problem for Franz Inc, and not a problem for
their customers. many customers also revert to lower-case mode simply
because it makes a lot more sense than upper-case mode does at this time.
that they don't talk about it has to do with the fact that some people
get _really_ upset whenever case is brought up, but it finally dawned on
me that we're _not_ talking about case, we're talking about which other
languages we want to communicate with, and case issues _follow_ from
that. it's not as if case is the primary factor of choice and we just
happen to like FORTRAN better than C. it's that to talk to FORTRAN, you
had to use the same case FORTRAN did, which were upper-case, but to talk
to C, you have to use the same case C does, which is in both cases. it's
a question of communication. of course, we can demand that other people
talk to us, and refuse to listen to their arguments. people who do that
on an habitual basis in real life, too, probably stick with upper-case in
Common Lisp, as well.

yet, however you wish to regard this, case-swapping is not something you
do without vendor support. Allegro CL already has all the support it
needs. in the case of CLISP or CMUCL, you're free to fix it yourself in
any way you want that doesn't have to be "portable" at all. that leaves
us with what Harlequin and Digitool would do if they were asked.

| Straightforward implementation-specific hacks won't work because the
| symbol name is stored in many places, not just in the symbol.

so let's do non-straightforward implementation-specific hacks, then.
(again, how hard can it possibly be to realize that when you have found
an obvious flaw in a given _solution_, you keep looking for solutions,
you don't just give up and shout the _inverse_ of "eureka!" and declare
the _problem_ dead and buried.)

| You could make duplicate symbols with lower-case names and copy their
| value, function, and plist slots, but this would probably break
| most compilers, which probably have code like (case (car form) (if ...

again, I would prefer to engage the creative part of the brain, not the
propaganda machine, when we encounter engineering problems. obviously,
this idea is really stupid, and so it's an indirect insult to would-be
proposers to assume that they haven't even thought about it. but, hey,
this is also something I'm trying to get you away from resorting to.

Common Lisp is often hailed as suitable for writing mini-languages. now,
instead of writing a _new_ mini-language, I think it's important that we
find a way for a fully conforming ANSI Common Lisp implementation to be
able to handle source code in :preserve mode, written in lower-case.
this is _obviously_ not a problem, since Common Lisp is good at writing
mini-languages. right? right! let's see if it is possible to turn code
written with :preserve and lower-case expectations into code that can be
compiled without changing much anything. this should be eminently doable
for the vast majority of cases. (if there be residiual problems, I hope
we can avoid more propaganda machine output and instead focus on solving
them or theorizing about the problems, not just sit down and wimper.)

| Or you could just tell beginners not to mess with readtable-case at all
| since the :upcase default generally does the Right Thing.

and that's what I've been telling you to do with your "special" hacks.
I'm relieved that you think this is an OK response to a silly proposal,
but in this case, I'm trying to show you that my proposal, which I sort
of expected you to dislike, is actually quite similar to your problem:
how to get people's expectations to fit the language they use, and vice
versa. you can't dismiss this _problem_, and I certainly did not dismiss
it in your proposals, but you can still dismiss proposed solutions.
that's why I wanted you to see the difference between bundling a problem
with a solution and having it rejected and looking a problem square in
the eye and determine to solve it by submitting a whole bunch of ideas
for other people's rejection and perhaps that one winner.

#:Erik

Coby Beck

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to

Erann Gat <g...@jpl.nasa.gov> wrote in message
news:gat-030300...@milo.jpl.nasa.gov...

| In article <3FIv4.5484$a82....@news.uswest.net>, "Frank A. Adrian"
| <fad...@uswest.net> wrote:
|
| > You know, I'm beginning to think that Erik is right and you really are a
| > brick.
|
| And I'm beginning to think that Erik is right, and stupid assholes like
| you ought to be dealt with harshly and severely


No, this is not right. Just have more patience. People with an ounce of maturity know
how to ignore that kind of behavior and will not let their opinion of you or what you
write be influenced in this way. The only good way to deal with comments like that is
to stay above it.

I guarantee you that i am not the only one who finds these constant put-downs to be
repugnant and a waste of everyone's time.

Coby


Lieven Marchand

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
Erik Naggum <er...@naggum.no> writes:

> argument to apply to programmers. most modern languages now have
> several sometimes _very_ powerful means of non-local transfers of
> control, such as exception handling. outside of Common Lisp, none
> of them make sanity maintenance convenient, what with all the
> declarations and "try" blocks and everything.

The best example of this was a series of 3 articles in "The C++
report" a few years ago in which some of the leading C++ gurus tried
to write a template stack class that was both exception safe and did
not leak memory no matter what the class of objects it was
instantiated with did. In the end, they had a complete mess of nested
try's and it still failed for one very pathological case (a destructor
that throwed an exception IIRC).

--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker

Harley Davis

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to

Erik Naggum <er...@naggum.no> wrote in message
news:31610529...@naggum.no...

> * Russell Wallace <mano...@iol.ie>
> | Can you give a reference to this, or summarize the argument in question?
>
> Pierre R. Mai relieved me (thanks!) of searching for the articles where
> Kent has made this point, but my understanding of this issue is that any
> language that has the ability to do non-local transfers of control needs
> a mechanism to ensure that invariants and pre- and post-conditions are
> maintained even across them. that is, _if_ you care about maintaining
> invariants and pre- and post-conditions (which could collectively be
> thought of the very sanity of your code), and that's where I extend this
> argument to apply to programmers. most modern languages now have
several
> sometimes _very_ powerful means of non-local transfers of control, such
> as exception handling. outside of Common Lisp, none of them make sanity
> maintenance convenient, what with all the declarations and "try" blocks
> and everything [...]

In Java there is unwind-protect:

try {
... some code that might throw an exception ...
} finally {
... clean up even if nonlocal xfer of ctrl ...
}

The thing that makes the Lisp unwind-protect much more useful is that it can
be combined with macros to implement control abstractions that clean up
after themselves properly, like with-open-file.

-- Harley

Frank A. Adrian

unread,
Mar 3, 2000, 3:00:00 AM3/3/00
to
My understanding of the operation was incomplete. Thank you for the
correction.
faa

Erik Naggum <er...@naggum.no> wrote in message

news:31610533...@naggum.no...


> * "Frank A. Adrian" <fad...@uswest.net>

> | In, other words, the inverse operation for defvar IS unintern.
>

Russell Wallace

unread,
Mar 4, 2000, 3:00:00 AM3/4/00
to
Pierre R. Mai wrote:
> For users of Deja, the following URL should give you all of the above
> articles (and some more). Read from early dates to late dates...

Ah, thanks! Interesting articles. I don't entirely agree with the
point at issue, but I do understand it now.

Tom Breton

unread,
Mar 4, 2000, 3:00:00 AM3/4/00
to
g...@jpl.nasa.gov (Erann Gat) writes:

>
> People are used to languages that are case-sensitive, where the default
> readtable-case (indeed the only readtable-case available to them) is
> :preserve, and where most keywords are lower case, or a mix of primarily
> lower case with some upper case.

> Common Lisp is case-sensitive like people expect. But the default


> readtable case is :upcase rather then :preserve, and the keywords
> (i.e. the names of the standard symbols) are all upper case.

ISTM this is a bad thing. One principle in programming is to make
your object names distinct (funciton names, variable names, whatever),
so they're not easily mistaken for each other.

Now, incorporating a word-similarity metric into a programming
language to disallow too-similar names is obviously a huge chore. But
one thing that can be done very easily is to disallow names that are
the same except for case. Just fold case, and they're the names that
collide.

So IMO case-folding by default is a good thing.

Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html.
Rethink some Lisp features, http://world.std.com/~tob/rethink-lisp/index.html

Marc Battyani

unread,
Mar 4, 2000, 3:00:00 AM3/4/00