Standardization of libraries

[mkatz@sesame.Stanford.EDU (Morris Katz)]

   Date: Fri, 24 Mar 89 03:37:33 PDT
   From: gyro@kestrel.arpa (Scott B. Layson)

      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


At Snowbird we already essentially created such a facility.  We called it a
library.  Jinx agreed to be the librarian for the first 6 months (I believe).
Users were encouraged to contribute modules to the library (with a preference
for those which could be run under many different versions of Scheme).  All
information in the library was to be available by anonymous ftp and possibly by
UUCP.  It seems to me that the reason that the library has not taken off is
that we still lack a standard mechanism for creating syntactic extensions.
This makes creating code which is executable on many different implementations
of Scheme very difficult.  It should be that any module should be able to be
composed of a series of segments (files) with only one of them being
implementation dependent.  Lets get syntactic extensions standardized, and the
rest will come along naturally.
					Morry Katz
					katz@polya.stanford.edu