Hello again,

OK, so let me be totally honest about this.  We see suggestions
several times a year for a new standard.  Every time, the suggestion
comes from a person who knows absolutely nothing about language design
or compiler technology, and the suggestion is basically just a list of
features that the person would like to see and that are not in the
current standard.  What the person then doesn't seem to know or
appreciate, is that the Common Lisp standard was created by a bunch of
very smart and very knowledgeable people, who carefully weighed each
feature, so that the combined language would be as coherent as was
possible, given the historical baggage, and so that they knew that it
would be possible to write a compiler that generates fast code.  Not
one single person suggesting any additional features have had any
knowledge of language design or compiler technology, and more often
than not, their suggestion would completely ruin the language
semantics, and also make it impossible to write a compiler that would
generate reasonably fast code.  This is why it makes me tired to even
comment on suggestions like this; I just have to explain over and over
why it is a bad idea, and I have to try to explain it to someone who
has absolutely no clue what I am talking about.  So much for the
technical aspect of it.

But there is also the non-technical aspect of it.  For some reason,
the people who make these suggestions seem to think that it is a huge
disadvantage for Common Lisp to have a standard at all.  Let me
explain what I mean.  These people are typically used to using
languages with a single implementation and with no standard at all,
like Python, C#, Java, Javascript, Haskell, etc., and they are not
bothered by that, it seems.  These languages evolve by some committee
getting together every so often to decide to include some new stuff in
the language.  Often, like in the case of Python, they don't even care
about generating fast code, because everyone writes C code for speed
anyway.  And these people also use third-party libraries without
blinking, whether the features of those libraries were approved by a
committee or not.  But somehow, to these people, the fact that Common
Lisp has a standard is now problematic.  To them, new features HAVE TO
be included in the standard in order for them to use these features,
but they don't have that requirement for other languages they use.
But having a standard that doesn't move is a good thing.  It means you
can make sure your code still works decades after you wrote it,
provided your system is conforming.  Somehow, these people are also
bothered by the fact that Common Lisp has several implementations.
They think it is totally important that every feature they use must be
included in every conforming implementation, so the only way forward
is to create a new standard, and force the implementations to follow
it.  But that is silly since they are perfectly happy to use a
language with a single implementation.  So why are they so
uncomfortable using a single Common Lisp implementation, like, say
SBCL?

So, in essence what these people are trying to do is to ruin the fact
that we have excellent backward compatibility, that we can have
compilers that generate fast code, and that we have several conforming
implementations that can run any conforming program.  This is of
course not their goal, but it would be the net effect.  For a new
standard to be even remotely successful, one would have to have
representatives for all creators of Common Lisp implementations to
participate and agree to the new features.  And that includes the
commercial vendors.  If a single person is attempting a thing like
this, it would most likely result in a new language, with a single
implementation, and a compiler generating slow code.  I for one would
not use that language.

Now lets look at each feature:

Extensible LOOP:

Sure, that's fine.  But someone would have to come up with a protocol
for that extension, and coming up with protocols is not a simple
thing.  It requires careful consideration to make sure the semantics
are sound, and one would have to make sure there are no bad
interactions with other LOOP clauses.

Improved hash tables:

The person who wrote that suggestion does not understand that the
:TEST keyword argument is intimately connected to the hash function.
It is not possible to just allow any old test function without also
specifying a hash function.  The standard can do it because the
functions are known.

Unifying variable declarations:

The person who wrote this does not seem to know the distinction
between a declaration and a binding.

Clear policy rules:

OK, I am fine with that.  This is the goal of WSCL, and not that with
WSCL I am only specifying stuff that almost every implementation
already does.  I am not inventing anything.

Standard parsers for lambda lists:

How is that going to be possible, given that the standard also allows
for an implementation to add new lambda-list keywords?  How is it
going to be specified where the additional lambda list keywords may be
found in the lambda list, how many there can be, whether they have any
arguments, what the shape of those arguments are?  I would need to see
some clarification here in order to even consider such a thing.  I
mean, I desperately want a widely accepted lambda list parser, and I
am working on it.  But it would be part of a library that people can
choose to use or not.  I would never put it in the standard.

CFFI:

I for one am totally against FFI.  Turning a (relatively) safe
language like Common Lisp into a totally unsafe language like C would
be a giant step backward.  It is fine with me if people want to use
the FFI of particular implementations, or CFFI if they like, but to
make it impossible for SICL to be called Common Lisp if I refuse to
include FFI in the system, I am totally against it.

Equivalence functions cleanup:

This suggestion implies that every implementation must have the same
representation for fixnums.  I would be totally against that.

Unicode support:

Sure, but the person suggesting this features must then explain what
CHAR-UPCASE does, or else remove that function and many others.

Long string literals:

Written by a person who does not know how to use read-time
evaluation.  I use #.(format nil "...~@..." for that.  Works fine.  No
need to change the standard.  In particular in this incompatible way.

Expand-full function:

Sure, why not.

Security:

Hard to tell what it means, but read-time evaluation can already be
turned off, so this problem doesn't exist.

Compilation:

Block compilation is a way to make the code faster by making
assumptions that can't change in the future.  But what if there are
techniques for making the code as fast anyway, without any particular
new feature (I am working on it).  Should we then force people to
include block compilation anyway in their systems, even though it is
not necessary, just so that others who are not that good with their
implementations can continue using inferior technology?

Extensible sequences:

As it says not trivial to make it fast.  I am sure some
implementations would refuse.

That's all I can handle today.  Maybe I'll do the rest some other day.

Take care,