Possible future SRFI ideas?

["Schol-R-LEA;2" <scholr1@comcast.net>]

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...