Autoload properties and stuff

[John L. Kulp <JLK at MIT-MC>]

Your comments are rather full of inconsistencies.  Making a macro
autoloadable does not make it part of the language.  If a user provides his
own definition of a macro, it does not affect other compiled code.  It is
certainly not the case that anywhere near everything that is autoloadable is
documented in the manual (new or old), and there are many other things
autoloadable which are not part of the language in any sense.

I hope your argument about in-fix notation is not misinterpreted as an
argument against keywords.  Also, the trouble with control forms is that
they do not naturally fit into the applicative notion of pure LISP.  While
I don't want to get in a position of defending in-fix notation, it seems
that it is occassionally a lesser evil when compared to completely convoluted
constructs one sometimes falls into with nested-list notation.  To me it
is more important for a program to be understandable, and I believe you
can judiciously use both in-fix, keyword, prefix, and nested-list notations
to achieve that.  It is just as fallacious to claim that using in-fix notation
results in less clarity as it is to claim that pure applicative style guarantees
clarity.  Both have to be used where it is appropriate, not where it results
in confusion.

You seem to have a rather arbitrary view of what should be in "primitive
LISP".  PROG, COND, and GO are adequate, so why have DO at all?  The answer
is obvious, as is the need for something like LOOP.  I do not claim the
LOOP is the ultimate win, but I have been screwed often enough by the
restrictions of the so-called "generalized" DO, that I think we need something
better.  I also doubt that a clean syntax can be found using nested-lists
that is as readable as one that uses keywords.  I find that ambiguous
notions like "LISP style" are abused almost as often as terms like "lexical
scope".  Pure LISP style, if it means anything, means a pure applicative
style which allows for no special forms.  If you allow special forms, then
you need a theory of what makes one "pure" or not.  It is not at all clear
that "pure" is equivalent to "useful".  Prefix notation and nested structure
are useful where they help connote semantic meaning, and they are a burden
where they inhibit it.  Similarly, universality and simplicity are nice
goals, especially for pedagogic situations, but they can also result in a
sort of unstructured homogeneity.

Your argument about English words is absurd.  Anyone who writes code with
short English words as names for functions deserves what he gets.  I suggest
just that opposite.  All English single words should be reserved for the
language, and the user should only use names with dashes or package prefices
(or otherwise non-words in the human language sense).  [This too is only
half-serious...]