[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Possible future SRFI ideas?

This page is part of the web mail archives of SRFI discuss from before July 7th, 2015. The new archives for SRFI discuss contain all messages, not just those from before July 7th, 2015.

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