[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible future SRFI ideas?
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
> * 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.