A modest proposal (long)
Erann Gat
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
| *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
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
> 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
| 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
> ...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
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
> 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
>>>> 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
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
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
> 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
"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
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?
>
> 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
> > 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
> 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
> 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
"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
| 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
| 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
> | 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
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
> 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
| 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
> 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
| 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
[ 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
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
> * 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
> 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
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
| 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
> > 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
> ...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
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
> Really?
Yes, really! I might like barbaric sports!
Tim Bradshaw
> 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
> 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
> 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
> [...] 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
> 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
> | > | 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 m