Fahlman's new new sequence proposal, and an issue of policy

[MOON at SCRC-TENEX]

CMU-20C:<FAHLMAN>NNSEQ.DOC seems to be a reasonable proposal; let's accept
it and move on to something else.  A couple nits to pick:

I don't understand the type restrictions for CONCAT.  Is (vector fixnum) a
subtype of (vector t)?  Is (vector (mod 256.)) a subtype of (vector t)?
Presumably all 3 of these types require different open-coded access
operations on VAXes, so if CONCAT allows them to be concatenated without
explicit coercions then the type restriction is inutile.  I would suggest
flushing the type restrictions but retaining the output-type specifier.
After all, the overhead is only a type dispatch for each argument; the
inner loops can be open-coded on machines where that is useful.  The
alternative seems to be to have implementation-dependent type restrictions,
something we seem to have decided to avoid totally.

mumble-IF-NOT is equally as useful as mumble-IF, if you look at how they
are used.  This is because the predicate argument is rarely a lambda, but
is typically some pre-defined function, and most predicates do not come in
complementary versions.  (Myself, I invariably write such things with
LOOP, so I don't have a personal axe to grind.)

REMOVE should take :start/:end (perhaps the omission of these is just a
typo).


A possible other thing to move on to: It's pretty clear that the more
advanced things like the error system, LOOP, the package system, and
possibly the file system aren't going to be reasonable to standardize on
for some time (say, until the summer).  As far as packages go, let's say
that there are keywords whose names start with a colon and leave the rest
for later; keywords are the only part of packages that is really pervasive
in the language.  As far as errors go, let's adopt the names of the
error-reporting functions in the new Lisp machine error system and leave
the details of error-handling for a later time.  I'd like to move down to
some lower-level things.  Also I'm getting extremely tired of the large
ratio of hot air to visible results.  There are two things that are
important to realize:  We don't need to define a complete and comprehensive
Lisp system as the first iteration of Common Lisp for it to be useful.  If
the Common Lisp effort doesn't show some fruit soon people are going to
start dropping out.

We should finish defining the real basics like the function-calling
mechanism, evaluation, types, and the declaration mechanism.  Then we ought
to work on defining a kernel subset of the language in terms of which the
rest can be written (not necessarily efficiently); the Common Lisp
implementation in terms of itself may not actually be used directly and
completely by any implementation, but will provide a valuable form of
executable documentation as well as an important aid to bringing up of new
implementations.  Then some people should be delegated to write such code.
Doing this will also force out any fuzzy thinking in the basic low-level
stuff.

This is, in fact, exactly the way the Lisp machine system is structured.
The only problem is that it wasn't done formally and could certainly
benefit from rethinking now that we have 7 years of experience in building
Lisp systems this way behind us.  From what I know of VAX NIL, Spice Lisp,
and S-1 NIL, they are all structured this way also.

Note also that this kernel must include not only things that are in the
language, but some basic tools which ought not to have to be continuously
reinvented; for example the putative declaration system we are assuming
will exist and solve some of our problems, macro-writing tools, a
code-walking tool (which the new syntax for LOOP, for one, will implicitly
assume exists).