I have been giving some thought as to some possible future SRFIs, and would
like some feedback on the ideas. In some case, groups of related proposals
are listed together, and likely dependencies are also given. I am assuming
for the moment that SRFI 33 will be either renewed and finalized, or else
supplanted, and that draft SRFI 56 will eventually finalize as well. Here
are some of the possibilities I have come up with:

* iterators and functionals library (see my previous posting)
* extended arithmetic and geometry library (not critical, since Scheme has
decent support in the core language, but there are always things to be added)
* vector and matrix mathematics libraries
* Integral and differential calculus libraries
* Soundex word-matching functions
* a simple object system (AFAICT, the last proposal didn't garner much
interest, though)
* Design by Contract framework
* optional static typing system (probably associated with the DbC system)
* build management (preferably a system that works transparently with both
interpreted and compiled code)
* version control (probably associated with the build management)
* automatic test scripting
* basic timing and profiling
* SQL bindings
* compression/decompression library
* cryptography library
* stroke-vector graphics library bindings
* bitmap image manipulation and I/O
* turtle graphics library bindings
* TCP/IP bindings and Socket support
* OpenGL bindings
* basic windowing-system bindings

Obviously, many of these are quite ambitious, and some of them are probably
not practical. In some cases (e.g., the cryptographic system), it would
probably consist of more than SRFI, with the primary SRFI providing a
general framework, and subsequent SRFIs providing support for specific
algorithms (e.g., MD5, AES, etc.). This follows the pattern used in certain
RFCs, where an initial paper defines a general protocol, then successive
papers may describe common implementations. This also follows the approach
used in several other languages (most notably Java) of providing a common
interface for a suite of related libraries (i.e., the Java Encryption
Services).

While this may seem a lot for a standard library, these are precisely the
sorts of things that have become increasingly common in language standards;
Java broke the dam on language libraries, by including windowing,
networking and so forth in the base library definition, and Perl has
widened it further. While not all of these may be appropriate for Scheme,
they are nonetheless typical of what is expected in standard libraries today.

A more serious objection is that in some instances, a reference
implementation would be excessively large or complex. This is one of the
reasons for the 'framework' proposal; it removes the burden of any specific
implementation from the general library, allowing the designer to
concentrate on the overall structure. Presumably, the framework reference
implementation would include a trivial example of the type (e.g., some
simple cipher such as ROT13) to allow confirmation of the reference
implementation's function.

Note also that for libraries with a high degree of system dependency (e.g.,
windowing), I only mention *bindings*; the actual behavior would still be
system dependent. There are two ways to address this is issue: either by
supporting only a very minimal set of bindings, such that are 'universal'
in windowing systems (assuming such an intersection exists), or else allow
the code to query the environment to determine what is and is not
supported. Either of these may prove too complex and/or contentious for an
acceptable SRFI to be defined.

Does anyone have anything to add? Some less ambitious and more immediately
useful examples would be a good thing :) Despite my interest, I am still a
newcomer to Scheme, and tend to see things from an outsider's viewpoint;
what do those who have worked with Scheme regularly see as the most
important gaps that should be filled?

Is there anything anyone feels does *not* belong on the list, and why? Keep
in mind that just because there is a 'standard' library for something, you
are not forced to use said library...