Guidelines for the Standard

[Christopher Fry <cfry@OZ.AI.MIT.EDU>]

	The existence of a large and fast-growing user community cuts two ways.
	On the one hand, for every change that we consider, we must think about
	not only the merits of making the change, but also the cost in terms of
	code that must be changed and users who must be retrained.
First, lets not distribute the changes piecemeal, but rather as a big lump.
Maybe this should be done every September?

I can imagine many changes to CL that would make the language easier to
use for BOTH experienced and new users. The spelling of RPLACA is
my favorite example. I'm afraid Scott would call these "aesthetic".
Well, you can acuse me of being an artist.

As far as changing code, we can provide programs and data that pretty much
do the right thing to source code. There will always be glitches, of course,
but things like changing the spelling of a function and changing arg order
can be done fairly reliably with a small program and a set of data to specify the
changes. Coral recently made a major name change in our underlying software.
I wrote a function which took as args, a list of source files,
an  alist of old-new name pairs, and a list of need-to-be-looked-at symbols.

The program creates new files that are the same as the old ones with
all symbols of old changed to new, and appends "???" to the end of
need-to-be-looked-at symbols. After the automatic conversion, I just searched
for "???" and did the necessary editing.
"???" was an argument, as was a suffix to be put on the names of the newly created
files.

A smarter program could distinquish symbols in function calling syntax from others,
recognize obsolete keywords, find certain reader macros, etc. All these tricks
are designed to reduce the number of need-to-be-looked-at contructs.

Such a converter program and its annual data could be kept in the yellow pages.
For obscure purposes, a converter could even go backwards using the same data.

CL could be a lot more consistent with itself.
Like, for instance, all list operators could take their primary list argument
as the first argument. Same thing for string, array and sequence operators.
A not-very-clever text modifier could even change CLtL with regards to
function spelling and arg order.

Scott is correct to point out that a constantly changing standard is
not a standard, and we do need a standard.
But a more consistent language would be easier to formally standardize,
learn, and remember. Ease of learning and remembering are key to
making any standard widely used.

Any mods will initially cost people currently involved with CL time. 
The issue is, how long will it
take them to pay for themselves in people-hours versus the life-expectancy of
the OLD CL? If CL is expected to grow, we must count the hours of the yet-to-be
CL hackers in the equasion.