🚀 go-pugleaf

The original article is clearly stirring much controversy.
I suggest we break the discussion into several major topics.

First is the general question of when is it appropriate to define a
standard and stick to it.  AI and its hype are coming out of the closet
of academic research and entering the commercial arena.  Your average
company is not interested in learning the pros and cons of five different
leading Lisp implementations (ie UCI, PSL, InterLisp, CommonLisp, FranzLisp
to name a few) and then identifying which commercial products are available
in which implementations.  Also, the commercial vendors are not interested
in reimplementing everything many times.  Thus, there are good and strong 
motivations of selecting a standard and going with it for a few years.
The Common Lisp implementors group (i.e. those who read fa.commonlisp)
are already talking about what should be in the current standard vs what
might be reserved for a future standard.  So I will not reply to minor
nitpicking, rather concentrate on what I perceive to be major issues.

Interpreter vs Compilers
I currently am working on a Lambda in Common Lisp and previously worked
in MultiLisp (developed by Halstead at MIT) on a VAX.  Since MultiLisp
did not have an interpreter, and since I come from a C development
background, I never (except for top-level commands) use the interpreter.
Incremental compilation takes a trivial amount of time and execution
is sooo much faster in compiled mode.  Thus, I wonder why anyone is
still concerned with interpreter implementations.  I note in passing
that Unix engineering workstations currently sell for less than $15000
and Kyoto Common Lisp sells for $700 object (written in C, provides
C interface to Lisp routines).  So do not complain about Common
Lisp only being useful for people who can get $125000 together.
Many of the original "difficult to implement efficiently" complaints
seemed to be related to interpreter issues.  I did not see why any
of those items would be difficult to generate good compiled code
for.

Which brings us to the question of Dynamic vs Lexical Scoping.
Coming from a C background, I find dynamic scoping to be
distasteful and lending itself to poorly engineered programs.
To understand the effects of lexical variables, the user/debugger
can rely on a static analysis of the source code.
To understand the effects of dynamic variables, the user/debugger
must understand the dynamic behavior of a running program.
It seems clear to me that the first is simpler than the second.

I further claim (here I deviate from Common Lisp) that there should
be a concept of "Global Lexical" variable.  Such a variable could
be masked by a function that happens to use the same name, but would
be available anywhere that it was not explicitly masked out.
This concept would allow those of us who find dynamic scoping
distasteful to completely avoid it.  Instead, we are told to
use *foo* as a convention to reduce the chance of a collision
with global special variables (that is, surround special variable names
with *s to make them stand out).

Parallel Implications - special variables also have significant
implications for rapid execution of parallel programs (if you
are not interested in speed, why both to execute parallel?)
In order that each subthread of the computation may have its own
value for a special variable if it has the appropriate declarations,
special variables must be supported by "deep" binding rather than
"shallow" binding.  This implemenation approach means that every
access to a special variable must be preceeded by a search down
a "current specials" stack or something similar to find the current
definition.  Global lexicals avoid this problem.

A challenge for those who prefer "dynamic" binding:
Show a short program (less than 40 lines) which demonstrates how
special variables make for a better (easier to read or faster to 
execute when compiled) program.