Lisp does not make an adequate syntactic distinction
  between [dynamic and lexical bindings].

That is very different from saying that dynamic binding is confusing.

Anecdotes like this only prove that some people get it right some of the
time, but I don't think there was ever any disagreement about that.
Perhaps even most people get it right it most of the time.  But it is
clear that not everyone gets it right all of the time, including, on
occasion, experts.  And that's the problem.  It's a problem precisely
because, as you say, dynamic binding *isn't* confusing, or at least it
shouldn't be.  Dynamic binding is a very simple and elegant concept.
There's no reason why everyone shouldn't get it right all the time, even
the experts :-)

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

That said, I don't consider much whether or not it is a design flaw
how Common Lisp treats specials.  The concern I have over any new
proposal is not how much better it might be, or even how hard it
would be to implement as a vendor.  What concerns me is the many
customers we have whose code would break if such radical changes
were made to the spec.  I don't remember seeing in the proposal
any indication of compatibility and what to look out for (though I
only skimmed it; there may be such treatment in the proposal, and I
apologize if I missed it).  What I would want to see is some
kind of study of what kinds of code would become broken by your
proposal, and how code can be kept from having to be changed.  Or,
as an alternative, a translator to change code of the older style
into the newer style (though that is much less acceptable than
not requiring any change to existing code).

We've had bugs in the handling of top-level closures in CMU CL, yet
I've never seen anyone claim that this indicates that closures are a
"pervasive(sic!) problem", and should therefore be "fixed".  It is
IMHO sufficient to fix the buggy implemention, and off we go.

Things might be different, if implementors consciously disagreed in
their interpretation of the intended semantics.  In that case the
standard would need to be fixed/augmented.

Yet it is IMHO fairly clear what the intended semantics of both lexical
closures, and special variables are.  But, as you might know, there is
a gap between knowing what to implement, and implementing it correctly.

That's why we have language implementors, and don't all implement the
language ourselves.

Regs, Pierre.

  A slightly more accurate nutshell summary would be just what I said:

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

  Most countries have laws that are fairly obscure and hence are neither
  commonly followed nor broken.  However, a universal legal principle is
  "ignorantia legis neminem excusat" (ignorance of the law excuses no one).
  It behooves the citizen of a country to know its lawa.  We find that more
  or less formal standards of good practice exists in every field of
  professional endeavor -- with the exception of programming computers.
  For some unfathomable reason, computers should be optimzed for those who
  are completely clueless, who cannot accept the responsibility for their
  own actions, who do nothing to rectify problems they run into, who are,
  plain and simple, _incompetent_ at their job.  Microsoft has clearly made
  a huge contribution to this state of affairs in its incessant propaganda
  that computers should be _so_ easy to use that actually learning to use
  them well has become a disadvantage.  However, failing to understand how
  something works, be it the society in which you live of the computer you
  use, can only lead to frustrations, complaints, and miserable experiences
  with the software you use.  So, too with programming languages.

  I believe that there is nothing whatsoever to be gained by catering to
  stupid and incompetent people.  Others, such as Bill Gates, believe
  otherwise, but in order to take advantage of stupidity and incompetence,
  you have to make a choice: Make yourself manifestly unattractive to good
  and smart people.  If a society catered to its criminals, good and smart
  people would leave that society, too.  This is why I think it is worth
  the pain to expose and get rid of those who have no desire to see their
  wishes in a context of a community that would have to (help) fulfill them.

  If there is a law we do not like, there are some exceptionally complex
  _laws_ to follow to change it.  It is not just in programming language
  communities that "cost to implementors" is considered and valueed higher
  than some "perfect solution".  If a society is made up of people who are
  so ill equipped to deal with disagreement that they throw up their arms
  and cry "design flaw" whenever their pet peeve comes up, they survive
  solely on the momentum of whatever processes allowed that society to be
  created and grow out of barbarianism and "might is right" to begin with..
  Sadly, many Western societies virtually surf on the waves made by those
  who were smart enough to figure out that need for legal infrastructures
  such as constitutions.  It takes a considerable amount of intellectual
  effort to see that freedom is achieved only within a society of just law,
  because most people who have not quite grown up mentally are still quite
  short-sigtedly egoistic and think that their desires are the law.  Some
  think this regardless of the consequences for others.  Those who hold the
  community interests above their own, or, more precisely, who adjust their
  own desires so that they do not require a different community than that
  in which they live, are generally much more successful in achieving their
  goals than those who spend their time wishing for a different community,
  society, world, or universe.

  If you stumble and fall, do you blame gravitation, meomentum, friction,
  or some other part of what we consider "laws of physics"?  If you stumble
  in your code and it misperforms, do you blemae physics for making it
  harder to type in correct programs, do you blame the hardware for not
  doing what you want, do you blame the compiler for not understanding you,
  do you blame the language specification for not being what you want?  If
  you get ill from a disease for which you were genetically predisposed, do
  you blame your God, do you blame your parents, do you blame your doctors
  for not fixing it, do you blame medicine as a whole for not being able to
  give you the life you want?  Or do you, in each of these cases, figure
  out that there are many things you cannot change and that it is useless
  to fight, that there are many things that just happen by coincidence and
  which have no conscious will behind them, that even if things seem wrong
  to you, they are in fact right for a lot of other people?

  You are rich if you can purchase whatever you want, whenever you want it.
  Corollarily, it depends more on what you want and when than on how much
  money you have.  The basic question is: Can you adapt to a society made
  by others?  Some are unable to do this and have to have their own will or
  they threaten to destabilize the society that made their very "protest"
  possible -- in a less civilized society, they would have been orstacized
  or killed, but because of the freedom they enjoy to express their views,
  they attack the very basis of that freedom.  These people are generally
  dissatisfied with some part of their society (and this will not stop --
  they are basically fighting _against_ the "establishment" and it will
  never be to their liking, because their role is a fighter, a role that
  would vanish if their "demands" were met) and act like the proverbial
  disgruntled postal workers instead of trying to find something more
  valuable to wast their life on.

  Are special variables in Common Lisp difficult to understand?  No, but
  let me rephrase the question to explain why: how much _education_ (as
  opposed to mere _training_) do you need to figure out what variable
  reference mechanisms exist and how they work and is this more than (1)
  any other feature in the language (it is clearly not), (2) any other
  features of other languages regarding non-trivial handling of bindings
  (it is clearly not).  What we have is a failure of some people to spend
  any effort _at all_ to learn how to use special variables, and those seem
  to think it is legitimate to fault the language for their lack of desire
  to expend effort to learn it.  So, the question is really, do we want to
  optimize a _language_ for the uneducated, untrained, unskilled moneky who
  coulud be replaced at a moment's notice or do we aim for the professional
  or professioal-to-be in both our education of beginners and in the design
  of our language?

  In yet other terms, do we recognize that knowing how anything works that
  is not exactly like something else you already know takes special effort?
  The first thing you learn is so simple and easy to internalize precisely
  because _nothing_ is there to get into a conflict with, but if you know
  one thing, like C's global variables, then your next thing, which will in
  _some_ way be different, will take some effort to understand.  Those who
  do not want to expend this effort, _assume_ that all things are the same
  and do not even want to recognize that they might be wrong when they run
  into problems.  This is flat out _stupid_ and betrays an _unconscious_
  modus operandi, which I consider to be _fundamentally_ incompatible with
  programming computers.  Those who fail to think even when the suggestion
  that they do so is presented by something as clear-cut as a failure of a
  computer do their bidding, should not be used as arguments to redesign a
  language that works perfectly well for those who _have_ learned it.  Such
  is no more than nihlistic change-for-the-sake-of-change and serves nobody.

  Common Lisp does _not_ have the luxury of being first contect, so those
  who discover it and want to learn it and use it productively have no more
  choice about having to expend the extra, but necessary effort to learn
  how it both exceeds and differs from other languages whose designers
  never dared to challenge the same design issues than those who wish to
  learn a physical skill that involved "unlearning" some bad habits, such
  as learning proper pronunciation in a foreign language, driving a car,
  becoming a master marksman, or even just typing faster on a computer.
  However, if the first thing an otherwise eager student sees when he is in
  this transition and re-learning period is some disgrunted ex-Lisper whine
  that so and so feature is a design flaw, the likelihood that he will want
  to expand that effort approaches zero faster than intelligent youngsters
  get rid of their desire to learn mathematics when presented with idiotic
  drills in arithmetic and a teacher who thinks real mathamatics is "too
  difficult".

  What we should do instead of this stupid whining about how badly designed
  the language is, is simply to show people what is on the other side of
  learning it well.  It is my personal opinion that those who gripe about
  bad design are unable to adapt their personal will to _any_ design not
  their own, and if my memory does not fail me, the same person who whines
  about special variables yet again also whined about how "impossible" it
  would be to use Common Lisp is real life applications, too, going all
  George Michael on us and "losing his religion" in the process.

Thank you,

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

While I fully accept that standard IT practice is to avoid any kind of
actual careful measurement of anything, preferring to make
billion-dollar decisions based on anecdotes, war stories, experience
from 30 years ago, badly taught university courses or, if pushed,
`measurements' so badly botched as to be useless both because of the negligible
scientific education of most computing people and because they aren't
actually interested in knowing the answer but in confirming their
prejudices, this doesn't mean that this is a good way to proceed.
Indeed, I think that it's pretty much our bounden duty as Lisp people
to try and drag the standard practice into the 19th century.

And Lisp is God's gift to this kind of study: source code is data!
We can write programs to analyse our programs and look for occurrences
of this kind of problem, if we wanted to.  Then we could *know* how
bad a problem it is rather than quoting anecdotes at each other!  Why
don't we do this?  Well I can think of two reasons: (1) quoting
anecdotes is kind of fun, and it might be inconvenient to actually
know it is or is not a problem. (2) It's not enough of a problem that
anyone can be bothered.

Finally here are some anecdotes, to keep the noise level good and
high.

I can not remember when I last wrote code that was confused about
special/lexical bindings.  I'm sure it's happened to me, but I doubt
it has been within the last 8 years.

I recently worked on a reasonably large system which was really pretty
badly written by people who didn't understand CL very well.  It had
many, many egregious problems.  Special/lexical confusion was not one
of them.

So there's two random stories.  I'm sure that there are plenty of
others showing the opposite.  However what I'm really sure of is that
STORIES LIKE THIS ARE WORTHLESS.

Ten years later I worked with two other programmers on one Cobol, well,
listing (early XP?). One of the guys never spoke except to say, "That
'o' should be '0'".

An acquaintance at a bar once showed up with a C++ listing from his
first programming class saying he had spent three days trying to get his
fifty lines to compile, and had resorted to running a virus detector in
desperation. I told him I had never done C++, but shouldn't that
<class>:<funcname> have another colon?

You shoulda heard the scream.

I think every language should have stuff like this to thin the herd.

--

You know, Tim, you are beginning to make me understand why Erik sometimes
responded to people the way he did.

BTW, Tim, as one of the few people who has actually published
statistically significant results concerning Lisp I would really
appreciate getting a little bit of the benefit of the doubt from you that
I might actually understand some of these issues.

Furthermore, for any argument at all to start, we'd have to find out
whether they made their "common" mistake _independently_.  Case in
point:

Just today we had the case that CMU CL and LW have a similar (the
same?) bug in their handling of declarations in clauses of
handler-case that don't bind the condition.  Do I start making
conjections as to "statistically significant" correlation of bugs in
CMU CL and LWW, without taking into account relevant context
information, like e.g. the strong possibility that this particular bug
might have one common source, based on the common reference
implementation, and hence is really just one bug?

And what is this nonsense about "the" mistake being predicted by a
theory?  Which theory?  It will obviously have to also predict that
CMU CL, LispWorks, ACL's compiler, ACL's old interpreter, CLISP, GCL,
... would not make that mistake (as seen in percentages).  If  you've
got a theory that can predict all of that, then I'm seriously
interested, and I bet most psychologists, too.  If your "theory" is
only that "special binding is a non-trivial thing to implement, hence
people might make mistakes _implementing it_", or even worse, the more
general "theory" that "people make mistakes", please don't bother...

Regs, Pierre.