This page lists SRFIs someone thought to be useful at some point.
Please use the official SRFI process as soon as you think you have a
good idea, since that will record the discussion and rationale for
each decision together with the SRFI itself. Use this page only if you can't submit a SRFI, or are actively looking for a basic starting idea.

SRE

SREs are Symbolic Regular Expressions. They are
implemented in SCSH.
Other ideas can be gleamed from the `rx' macro in Emacs.

added comment: The scsh documentation seems to be specific to strings, if the SRFI is going to be specific to strings, lets identify it that way, maybe SSSRE's, (String Specific Symbolic Regular Expressions) as compared to the generalized case of doing regular expressions on symbols via equals? rather than just checking if charactors are equal in a string. The latter would be a special case by (string->list x) (but obviously less efficient). The former is a generalization of patern matching

Matrix Library

A library for manipulating mathematical matrices would be wonderful,
especially if the reference implementation could be fast :-)

Formatting

The current SRFIs which treat formatting (SRFI:28 and SRFI:48)
are using strings for formatting. A library which uses lists instead
would be a good idea. Look at SRFI:54 for a sample on how to do
some kind of formatting in such a formatting proposal.

Am I alone in being *completely* lost in the maze of astonishingovercomplexity that is SRFI 54?

This could basically be combined with SRFI:54 in that it just
defines the quite common procedures (probably with better names).

Riastradh has also constructed an informal proposal for a macro-based
formatter, riastradh-format.

Consideration: efficiency

It's quite inefficient to construct a lot of strings by appending
etc., it's much more efficient to keep a structure and walk this when
outputting. riastradh-format addresses this by providing a
formatting mini-language. Another common approach is to have a
procedure which displays a tree of values, so you can construct the
tree and the procedure just walks it:

This is not as efficient as the minilanguage approach (it still needs
to construct the pad string), but it's a close approximation.

Output Combinators

Output combinators have several advantages:

Simplicity: Compare the output combinators below with a typical CL
format implementation, or consider the complexity of a
hypothetical implementation of Riastradh-FORMAT. The design,
implementation, and usage of output combinators is considerably
simpler overall than either of those two options. Output combinators
are also composable; see below on that.

Generality: Unlike the tree-based or string-based approaches above,
output combinators are not restricted by a static, inextensible
procedure to display trees (e.g., display-tree above) or by
operations on strings, which, e.g., write is not. Furthermore,
because the structure of output procedures is so simple, we can bend
it to do very sophisticated tasks that would be difficult in CL
format or Riastradh-FORMAT; e.g., if we are constructing C
code as output, we could have a (with-c-indentation countitem) combinator whose result is like item but that,
when item is invoked, binds a C indentation fluid for other
output procedures to use in order to produce proper indentation.

Composability: One can take two output combinators and compose them
easily. One is not restricted by imperative sequencing except in the
implementation of output combinators such as sequence; once such
combinators are built, though, they can be re-used and combined with
others trivially. With-c-indentation, c-block, &c., are
excellent examples of composability.

Efficiency of development: It's quick to develop new combinators on
demand. They're easy (and fun!) to write, and they require no
framework like a CL format dispatch structure to fiddle with.

Efficiency of performance: I have no numbers to support this claim,
but output combinators have no interpretive overhead, while CL-style
format does. That is, there is no code that must analyze some
other code (a format control string) as the output is being produced.
Using output combinators has pretty much the same effect as a CL-style
format compiler; indeed, such a compiler would probably be based
on an output combinator library, or something very similar thereto.

Here is a simple implementation of some output combinators. Note that
there is no framework imposed by the device; output procedures are
simply unary procedures that accept ports and write output to them,
and output combinators are simply procedures that return output
procedures. We need no format dispatch table or mini-language
compiler or anything like that. This code makes trivial use of
SRFI:1 as well as some Scheme48-specific features such as
fresh-line, which is like newline but on some ports where
it is supported does not create a new line if it is on an empty line,
and char-sink->output-port, whose name and usage are
self-explanatory.

Incidentally, this output combinator device is also a monad, if we
take this definition of the extend operator (also known in
Haskell circles as bind or >>=) and the unit
operator (also known as eta and return):