perm filename CHARTE[COM,LSP] blob sn#780207
filedate 1984-12-26 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00002 00002 Charter
After reading Scott's message, which hinted at a potential charter
proposal he may write, I was thinking further about my loathing
of democracies and the possible dangers to Common Lisp if we go for
such a system.
But first, some other comments.
1) Why do we need a non-profit organization that needs ARPANET access? We
possibly need such an organization to shield us as individuals from
lawsuits. And I can almost see that we might need such an organization to
provide dollars for travel to meeting places. But why ARPANET access? Will that
organization be manned? (!) And what will the person who mans the organization
do every day? I presume that what we'll need is an organization in a city
where one of the permanently interested Common Lisp people can have a
post office box and a bank account.
2) We've always dealt with issues by ARPANET before; why can't we do that now?
The number of new accounts that are needed for people who do not now have
ARPANET access is pretty small, and the bulk of the costs of those accounts
can be paid for either by the companies involved or by DARPA for the individuals
3) Validation could form the basis of a `company,' and for that we should
possibly charge a validation fee, and DARPA can pay for the rest of the
validation activities. Perhaps we could study how ADA is validated (or
not validated) to understand how to win (or how to not lose).
Now on to voting.
When we were doing the original design, we relied on consensus, not on voting.
We voted from time to time, but we accepted the results of the vote as binding
in those cases in which we had agreed by consensus to accept them. We didn't
trust voting then, and I don't think we should trust it now. We ought to
allow voting for getting the sense of how people feel, and for simple
decisions voting is ok, but for any sort of major decisions I think
we would be nuts to use it.
If companies are paying to send members to a standards meeting, then you
can bet that it will be tough for some people to dissociate themselves from
their companies. It is nice to think that people will be able to put themselves
in the larger context to vote on the issues qua issues, but I'd rather have the
structure set up to enforce this.
There are two ways I can think of, and they are similar to each other. The first
is a statement of principles, which states exactly what it is that makes
Common Lisp a Common Lisp. In some sense we want that definition to change
is needed, but we want to guarantee that the rate of change will be small for
most of the language. And we want some parts to move very slowly indeed.
The principles would state that Common Lisp is a lexical Lisp and, for example,
that a dynamic Lisp is not to be interpretted as a subset of Common Lisp.
Similarly it would also talk about multiple values, lambda-lists, and the
general principles, which Steele stated in the Common Lisp book.
There would then be a body that would decide for every change made to
Common Lisp whether that change followed the principles. If not, then the
change would not go into effect. This body could also serve an advisory
role with respect to other Common Lisp activities.
The second way is a simplification of this, which is to have an oligarchy.
The members of the oligarchy would be chosen for their `stature' and
`Lisp wisedom.' A second body would be a suggestion-generator. This second
body would come up with proposals, and the oligarchy would decide what to do.
This is almost the same as the first suggestion, but there is no set of
principles that form the basis of the decisions made by the oligarchic
On the subject of dues, it might be the case that some small startups cannot
afford, say, $20k right off the bat. These companies might like to offer
services rather than dollars in order to `belong' to the Common Lisp Group.
That is, they could run mailing lists, work on validation suites, or something
until their ship comes in.