A comment on our community.

[greek@DEC-HUDSON]

It seems pretty clear to me that the Common LISP community can't agree
on anything too controversial such as flavors, graphics, error handling,
windows, etc.  My experience with trying to set up a registration
service for package names, which has all but died, left me with a similar
feeling.  I received notes with comments like "Well, this isn't an
official statement, but my company probably wouldn't use the registrar."

We should all run for Congress.  Seriously, though, those of us who
work on existing implementations should admit that we have a vested 
interest in our current flavor system, graphics system, etc.  Those
of us who work for profit-making organizations should admit that we
want an edge over our competition.  And we should all admit that, as
"computer scientists", we're probably some of the most gratuitously
opinionated people around.

If we really can't agree on something, let's just say so and leave it
at that.  What I'm really afraid of is oversimplified or abbreviated
proposals which address small subsets of the problem.  In particular,
if we ever do manage to agree on the bigger problem, we will end up
with the original burp in Common LISP that looks out of place.

I don't want to attack Kent's proposal as some kind of ill omen, but
these simple character-oriented functions don't address a lot of
problems.  How does LISP know how to do them?  What do some of 
them mean on a bitmapped terminal?  Do you really want to try to
program portable algorithms by continually using SCREEN-OPERATION-
HANDLED-P and having multiple code paths?  Earl, Tim, and Rob have
pointed out other issues.

Let's face it, windows, graphics, and text display are not solved
problems.  Why do we think we can agree on them?   Perhaps our time
is better spent on topics we're more likely to resolve, such as a
kernel object-oriented subsystem or error handling facility?
But please let's agree that a lot of politics is involved here.

- Paul