At Mon, 19 Jul 2004 12:52:15 -0700, Schol-R-LEA;2 wrote:
>
> I have been giving some thought as to some possible future SRFIs, and would
> like some feedback on the ideas.

You'll probably get a better response on comp.lang.scheme, this list
is more for discussion about the SRFI process itself.  And a wishlist
is of limited use; it's more productive to choose one thing and try to
get a SRFI done on it.  Even a withdrawn SRFI can be a good reference
and learning experience for the community.  And if you can't manage a
reference implementation yourself, you could consider petitioning
someone who's written such a library to write a SRFI :)

> * iterators and functionals library (see my previous posting)

SRFI-42 is a superset of this, but simple while/until loops and
when/unless are useful enough that they're already included in many
implementations.  But I don't think you'll get much support on a FOR
loop - either use SRFI-42 or go all they way and write a CL LOOP SRFI.

> * Soundex word-matching functions

This is cute and many Schemes have it, but I don't really see the
point in it.  I can't imagine anyone choosing this over a universal
hash these days.

> * a simple object system (AFAICT, the last proposal didn't garner much
> interest, though)

If we get a SRFI for inheritable records, with or without multiple
inheritance, we can build on top of it a separate, orthogonal method
dispatch SRFI (or several to choose from), which is more likely to get
support than a single, all-in-one OO system proposal.

> * automatic test scripting

Already lots of portable test libraries.

> * basic timing and profiling

Lots of these, none portable.

> * SQL bindings

Preferably in 3 tiers: 1) backend, 2) general DBI-like interface, 3)
more Scheme-like interface so you don't have to do manual string
compositions to build complex queries.  SchemeQL is an interesting
start but as a macro is not composable.

> * compression/decompression library

with-input-from-compressed-file :)

> * cryptography library

I think most Schemes have MD5, and there's a portable implementation,
so this would be easy.

> * TCP/IP bindings and Socket support

Or just a POSIX SRFI.

> * OpenGL bindings

Several Schemes already have this, we just need a standard interface.
And syntactic sugar.

> * basic windowing-system bindings

Choose one (like Gtk which is already supported by several Schemes)
and standardize the API.  We're a long way off from a universal
windowing API, unless you want to directly adopt CLIM.

--
Alex