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

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

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.