[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Standardization of libraries
Date: Thu, 23 Mar 89 17:25:09 PST
From: Pavel.pa@Xerox.COM
This whole exercise seems entirely misguided to me. I have not seen you
(or anyone) respond well to Morry's objection that any ``appendix''
constitutes a standard with inertia of its own.
I don't think the exercise is *entirely* misguided. Unless we take
the attitude that we literally don't care whether we have a user
community or not, we are going to have to pay some attention to the
needs of that community. The question is what kind, and how much, and
at what cost to our goal of facilitating exuberant experimentation
among implementors.
The problem, of course, is that there is a natural antagonism between
encouraging ferment and the needs of users for stability. I daresay
the general sentiment is that we consider ferment much more important
than do, say, the Common Lisp designers. (I don't think this goes
without saying -- I could make a case for the point of view that if we
want Scheme to be really widely used, we should go into "product
support" mode as quickly as possible -- but for the moment I will take
it as a given that our priority is ferment.)
So then the question becomes, is there any way we can have ferment and
still give our users what they need? I think there might be, though
it will take some effort to do, and that it will look roughly like
this:
-- In the Scheme standard (this applies equally to the RnRS
leading-edge standard and the IEEE "trickle-down" standard) we
make absolutely every attempt to specify the minimum language in
which all else can be written. In short, we want the standard to
specify a basis set of programming constructs, and nothing else.
-- This means that *anything* that can be written in terms of the
standard constructs must not be part of the standard. This
includes the kinds of things we have been discussing: top level
loops, error reporters, etc.
-- To make it possible to write portable programs that make use of
such facilities, we resort not to the static approach represented
by a document, but rather to a dynamic approach: an official
module registration facility.
The idea of the module registration facility is that anyone who thinks
they have a module (subsystem, collection of functions, whatever you
want to call it) that would be of general interest can register it,
that is, make it publicly available under a unique name. The module
could be something completely new, or it could be only a variation
(preferably not a totally trivial variation) on some other registered
module. Once a module is published, the only allowed changes to it
are bug fixes, compatible performance improvements, and upwardly
compatible extensions.
Users, then, need only list the modules to be used by any given
program. Once the program is written, the user never need update it
to use more recently released modules, although that is always an
option. Implementors need not concern themselves with modules at all,
except insofar as we may decide to add a construct or two to the core
language to support their use.
Note that when I say "a module registration facility" I don't mean a
facility in the linguistic sense, like Common Lisp's PROVIDE /
REQUIRE; I mean an office with a budget and a staff, you know, humans.
Well, with luck it would only take a fractional human. The tasks
would be 1) to assign the unique module names; 2) to maintain a
library containing the source code for each registered module; and 3)
to fill orders for copies of said source code.
It's an institutional rather than linguistic solution, but then I
think the problem is more a social one than a technical one to start
with.
Comments?
Scott